代码改变世界

前端工作流规范

2019-11-24 01:25  龙恩0707  阅读(...)  评论(...编辑  收藏

阅读目录

一. 项目版本规范(或API组件开发)

项目的版本号推荐使用语义化版本规范(https://semver.org/lang/zh-CN/), 其基本规则如下:

版本号定义: <主版本号>.<次版本号>.<修订版本号>; 比如 1.0.0,采用 X.Y.Z的格式规范,且X, Y 和 Z 为非负的整数。 其中 X 为主版本号, Y 为 次版本号, Z 为修订版本号。

升级原则:

1) 主版本号:功能模块有大的变动时,比如API兼容性做了修改或整个架构发生了变化。
版本号需要递增, 次版本号和修订版本号必须归零,比如 1.1.5这个版本,现在组件的API兼容性发生改变或整个项目结构发生改变,那么主版本号需要递增,因此这个时候版本号变成为 2.0.0;

2) 次版本号: 当模块或组件增加新功能时 或 一些公用的API功能被弃用的时候,也需要递增。
每次次版本号递增时,修订号必须归零。比如 1.1.5 版本,现在模块或组件增加新功能时,那么次版本号需要递增。因此现在的版本变成了 1.2.0;

3) 修订号: 当功能模块或组件的bug修复, 或功能扩充等。
修订使指项目中的bug修复,那么版本号需要递增。比如 1.1.5 版本,现在bug修复好了,那么现在的版本变为 1.1.6了。

二:版本控制系统规范(GitFlow)

GitFlow概念: GitFlow是使用一个中央代码仓库,它是所有开发者的信息交流中心。它和其他工作流程一样,开发者在本地开发完成,然后将分支代码推送到中央仓库。不同点在于项目中的分支结构。
可以参考:(https://nvie.com/posts/a-successful-git-branching-model/)

使用GitFlow, 在项目中会存在两个长期分支,主分支(master) 和 开发分支(develop)。

主分支(master): 该主分支代码用于对外发布的代码(一般指线上已经发布的)。

开发分支(develop): 用于日常开发。该分支是基于master分支克隆的, 编码工作在该分支上进行。

功能分支(feature): 该分支是基于develop分支克隆的。该分支的作用主要用于一些新功能的开发,功能开发完毕后需要合并到develop分支。
feature分支可以有多个,它是属于临时分支,当某个功能实现后可以删除该分支。

测试分支(release): 它是基于develop分支克隆的,产品编码工作完成后,需要把测试分支代码发布到测试环境中,如果在测试环境中发现了一些小bug,那么就直接在该分支上进行修复操作。等测试所有完成后,我们需要把该分支代码合并(merge)到develop分支上。
该分支也属于临时分支, 当功能实现后也可以删除该分支。

Bug修复分支(bugfix):  该分支是基于master分支或Tag标签进行克隆的。作用主要用于修复对外发布的分支。修复完毕后,需要分别合并到develop分支和master分支上。本分支也属于临时分支,功能完成后也可以删除该分支。

基本步骤如下:

1. 从远程仓库克隆代码到本地仓库,基本命令比如如下:

git clone https://github.com/tugenhua0707/gitflow-test.git

2. 在master分支上,创建develop分支,基本命令如下:

// 切换到master分支上
$ git checkout master
// 基于master分支克隆develop分支,并且切换到develop分支上
$ git checkout -b develop
// 推送develop分支到远程仓库
$ git push origin develop

3. 在develop分支本地仓库基本流程

当某个功能点开发完成后,我们需要将代码提交到本地仓库。

// 提交到缓冲区
$ git add .
// 提交修改到本地仓库
/*
   如果是修复BUG的话,则注释可以为: "Bug 修改说明"
   如果是完成了某一个功能的话,则注释可以为: "Task 修改说明"
*/
$ git commit -m "Bug 修改说明"

4. 推送代码到远程仓库

当我们完成一个功能点或阶段工作时,需要将代码推送到远程仓库develop分支上。

// 先拉取最新代码, 防止代码冲突
$ git pull
// 解决代码冲突后/或代码没有冲突的话, 我们需要将develop分支代码推送到远程仓库中
$ git push origin develop

5. 功能分支(feature)

此时此刻,我们项目中某一个模块需要添加一个新功能,我们可以在develop分支上克隆一份代码来, 然后进行对应某个功能开发。当然在团队
合作中,我们可以创建多个功能分支。比如叫 feature1,feature2,依次类推来命名....

// 从develop分支中克隆一份代码下来,且切换到对应的 feature1 功能分支上。
$ git checkout -b feature1 develop

// .... 然后进行开发,开发完成后提交代码到远程仓库

// 功能开发完成后,我们需要把该功能分支再合并到我们的develop分支上, 切换到develop分支上来,然后进行如何合并命令
$ git merge feature1

// 合并完成后该分支,我们可以把该功能分支删除
// 删除本地分支
$ git branch -d feature1 
// 删除远程分支
$ git push origin --delete feature1

6. 将代码发布到测试分支(release)

如上在develop分支上代码开发完成后,我们需要提测到测试环境中,因此我们需要将代码发布到测试分支release。

执行基本命令如下:

// 切换到develop分支上来
$ git checkout develop
// 创建并切换到release分支来
$ git checkout -b release
// 推送到远程仓库中
$ git push origin release

// ..... 在测试中有bug时,直接在该测试分支(release)中修改。

测试完成后,需要将 测试分支(release) 代码合并到develop分支中。

// 切换到develop分支上
$ git checkout develop
// 执行合并操作, 将release分支代码合并到develop分支上(如果有冲突,需要解决冲突,再合并)
$ git merge release

当开发和测试代码都没有问题的时候,需要将代码发布到线上后,此时需要把develop分支代码合并到master上。

// 先切换到master分支
$ git checkout master
// 合并develop分支代码
$ git merge develop

7. 线上发布完代码后,需要打开Tag(里程碑Tag包)

// 创建里程碑Tag
$ git tag -m "Task v1.0.0发布" v1.0.0
// 推送里程碑Tag到远程库
$ git push origin v1.0.0

8. 发布完成后,线上Bug修复工作流

1) 获取到Bug产品的软件发布的版本号

2) 基于里程碑Tag创建分支:

// git checkout -b [创建的分支名称] [里程碑Tag的名称]

$ git checkout -b bugfix-v1.0.0  v1.0.0

// 就会创建一个 bugfix-v1.0.0 分支,然后进行修改.

3)修复代码完成后可以使用如下命令查询修改过的地方

$ git diff

4) 修改完成后分别合并到develop分支和master分支上

/* 合并到develop分支 */
$ git checkout develop
$ git merge bugfix-v1.0.0
// 提交到远程仓库develop分支下
$ git push origin develop

/* 合并到master分支下 */
$ git checkout master
$ git merge develop
// 提交到远程仓库master分支下
$ git push origin master

5) 创建新的里程碑Tag

$ git checkout master
$ git tag -m "Bug 修复某某bug" v1.0.1
// 推送到远程仓库中
$ git push origin v1.0.1

三:github Issue 任务管理

github Issue是目前相对来说比较流行的任务管理工具,它可以帮助我们了解项目的进度、资源的分配情况。

在团队协作中,每个issue可以代表一个任务,我们的每一项任务可以创建一个Issue,Issue的完成后由自己关闭掉。

每个Issue应该包含问题的标题和描述信息,使后来的人一看标题和描述就可以知道该issue是那个项目下的,该项目会有那些基本功能点。

3.1 基本用法

在我们的Github代码仓库中都有一个Issues面板,如下图所示:

1)在如上所示的 Filters 中,我们可以对分类进行过滤查询。方便管理所有的类目。

2)在如上所示的 Labels中,Issue可以贴上标签,有利于分类管理和过滤查看,默认有9个标签。我们可以对9个默认标签进行修改或删除操作,我们有可以新建自己的标签,如下图所示:

对于一些稍微大一点的项目,每个Issue至少应该有两个Label, 一个表示性质, 另一个表示优先级的。

表示优先级的Label,可以参考下面的级别:

高优先级(High): 表示对系统有重大影响,只有解决它之后,才能完成其他任务。
普通优先级(Medium): 对系统的某个部分有影响, 用户的某一部分操作会达不到预期的效果。
低优先级(Low): 对系统的某个部分有影响,用户几乎感知不到。
微不足道(Trivial): 对系统功能没有影响,一般是视觉效果等,比如字体或颜色不满意。

添加如上标签后,如下图所示:

3) 在如上的 Milestones 中,它叫做里程碑,用作Issue的容器,相关的Issue可以放在一个 Milestone 里面。

我们可以新建一个 Milestone, 在Issues面板的首页,点击Milestones按钮。然后我们再接着点击 New milestone 按钮,然后填写 Milestone的名称和内容,可以指定到日期时间,如下图所示:

在如上设置完成后,我们就可以创建一个Issue了,进入Issue面板,点击新建 "New Issue" 按钮。就会进入新建Issue页面,如下图所示:

如上就是新建Issue界面,左侧是填入Issue的标题和内容,右侧是四个配置项。我们分别来看下右侧四个配置项的具体含义:

Assignees: 人员
Labels: 标签
Projects: 项目
Milestone: 里程碑

Assignee

Assignee 选择框用于从当前仓库的所有成员之中,指派该Issue给某个人,目前我这边只有我自己,如下所示:

如上我们只要选择一个人即可。

Labels

Issue 可以贴上标签,这样有利分类和过滤查看,如下是我刚刚新建的所有标签,如下图所示:

新建完成后,可以变成如下看到,如下图所示:

Projects: 指具体的那个项目,我这边目前,可以为空,不填吧。

Milestone: 指里程碑,也就是可以理解为该项目什么时候完成的。如下图所示:

如上就是我们刚刚新建的日期时间。

新建一个Issue如下所示:

然后效果就变成如下所示:

最后填写完成后,我们点击最右侧下面的 "Submit new issue" 按钮,即可提交,然后我们就可以在Issue面板中可以看到我们的issue列表信息了,如下图所示:

当我们的这个项目有任何功能点已经完成了,或者状态发生改变了,或者上线了(如果上线了,我们需要关闭该项目)。我们需要自己手动去改变该项目的状态,如下图所示,进入该项目的目录下进行更改状态:

如上该上面完成及上线后,我们需要关闭该issue,因此我们可以点击该issue的详情页,点击最底部的 close issue 按钮,如下图所示:

如上就是github中的issue在团队协作中项目管理的基本操作了。

待续更新中........