许多公司的开发团队都采用 Git 来做代码版本控制。如何有效地协同开发人员在开发、测试、上线各个环节的工作,可能都有各自的流程与规范。本文就分享作者一直沿用的团队项目 Git 分支管理规范,希望给有缘阅读的人加以参考,如果有更好的实践,也欢迎探讨、交流,谢谢!
### 分支管理
#### 分支说明
创建项目时,会针对不同环境创建几个常用分支:
- **master**:主分支,负责记录上线版本的迭代,该分支代码与线上代码是完全一致的。
- **develop**:开发分支,该分支记录相对稳定的版本,所有的 `feature` 分支和 `bugfix` 分支都从该分支创建。
- **release**:发布分支,用于代码上线准备,该分支从 `develop` 分支创建,创建之后由测试人员发布到测试环境进行测试,测试过程中发现 bug 需要开发人员在该 `release` 分支上进行 bug 修复,修复完成自测没问题后,在上线之前,需要合并该 `release` 分支到 `master` 分支,同时需要再合并该分支到 `develop` 分支。
平时开发工作中,会根据需要由开发人员创建几类临时分支:
- **feature**:特性(功能)分支,用于开发某个特定的功能,该分支从 `develop` 分支创建,不同的功能创建不同的功能分支,开发完成自测没问题后,需要合并该分支到 `develop` 分支,之后删除该分支。
- **bugfix**:bug 修复分支,用于修复某个普通的 bug,该分支从 `develop` 分支创建,修复完成自测没问题后,需要合并该分支到 `develop` 分支,之后删除该分支。
- **hotfix**:热修复分支,用于修复某个紧急的 bug,该分支只有在紧急情况下使用,该分支从 `master` 分支创建,用于紧急修复线上的 bug,修复完成自测没问题后,需要合并该分支到 `master` 分支,以便上线,同时需要再合并该分支到 `develop` 分支,之后删除该分支。
#### 分支命名规范
#### 特性(功能)分支
该分支的分支名称应该为描述该功能的英文简称:
```
feature/分支名称
```
例如,开发的功能为“新增商品到物料库”,则可以创建一个名为 `feature/material-add` 的分支。
#### bug 修复分支、热修复分支
该分支的名称应该为 Jira 中 bug 代码或者是描述该 bug 的英文简称:
```
bugfix/分支名称
hotfix/分支名称
```
比如,修复的 bug 在 jira 中代号为 MATERIAL-1,则可以创建一个名为 `bugfix/MATERIAL-1` 的分支。
#### 发布分支
该分支的名称应该为本次发布的主要功能英文简称:
```
release/分支名称
```
比如,本次上线的功能为“新增商品到物料库”,则可以创建一个名为 `release/material-add` 的分支。
### 流程规范
#### 正常开发流程
1. 从 `develop` 分支切出一个新分支,根据是功能还是 bug,命名为 feature/* 或 bugfix/* 分支。
2. 开发者完成开发,提交该分支到远程仓库。
3. 开发者发起 `merge request` 请求(可在 `gitlab` 页面 `New merge request`),将新分支请求合并到 `develop` 分支,并提醒组长或同事进行 `code reviewer`。
4. `code reviewer`后,若无问题,则接受 `merge request`,并将新分支合并到 `develop` 分支,同时可以删除新建分支;若有问题,则不能进行合并,可 `close` 该请求,同时通知开发者在新分支上进行相应调整,调整完后提交代码,重复 `code reviewer` 流程。
5. 转测时,直接从当前 `develop` 分支合并到 `release` 分支,重新构建测试环境,完成转测。
6. 测试完成后,从 `release` 分支合并到 `master` 分支,基于 `master` 分支构建生产环境完成上线,并对 `master` 分支打 `tag`, `tag` 名可为 `v1.0.0_2019032115`(即:版本号_上线时间)。
流程示意图如下:

#### 并行开发测试环境 Bug 修复流程
并行开发(即前一个版本已经转测但未上线,后一个版本又已在开发中并部分合并到了 `develop` 分支)过程中,转测后测试环境发现的 bug 需要修复,但是 `develop` 分支此时又有新内容且该部分内容目前不计划转测,可以从 `release` 切出一个 bug 修复分支,完成之后需要同时合并到 `release` 分支与 `develop` 分支,合并时参考“正常开发流程”。
流程示意图如下:

#### 生产环境 Bug 修复流程
生产环境的 Bug 分两种情况:
1. 紧急 Bug:严重影响用户使用的为紧急 Bug,需立即进行修复,如关键业务流程存在问题,影响用户正常的业务行为。
2. 非紧急 Bug 或优化:非关键业务流程问题,仅影响用户使用体验,或出现频率较小等,为非紧急 Bug,可规划到后续版本进行修复。
非紧急 Bug 修复参考“正常开发流程”。
紧急 Bug 修复,需要从 `master` 分支切出一个紧急 bug 修复分支,完成之后需要同时合并到 `master` 分支与 `develop` 分支(如果需要测试介入验证,则可先合并到 `release` 分支,验证通过后再合并到 `master` 分支上线),合并时参考“正常开发流程”。
流程示意图如下:

### 参考资料
[团队项目的 Git 分支管理规范](https://www.cnblogs.com/spec-dog/p/11043371.html)
[研发团队 Git 开发流程新人学习指南](https://cloud.tencent.com/developer/article/1395975)
[Git 分支管理规范](http://www.360doc.com/content/20/0117/15/14542013_886689840.shtml)

团队项目的 Git 分支管理规范