前端工作流规范

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

阅读目录

一. 项目版本规范(或API组件开发)
二：版本控制系统规范(GitFlow)
三：github Issue 任务管理

回到顶部

一. 项目版本规范(或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): 对系统功能没有影响，一般是视觉效果等，比如字体或颜色不满意。

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