前端工作流规范

阅读目录

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

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

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在团队协作中项目管理的基本操作了。

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