开发过程当中的git分支管理

1、介绍

本文介绍一种多人参与开发时的 GIT 分支管理模型，在团队项目中成功实践。使用的是gitlab来作代码管理与权限控制。

2、服务器部署环境

通常来讲，服务器端分如下几种运行、部署环境：

• staging：用于开发功能时给 RD 测试用，代码、数据库都是测试环境的。

• preview：用于代码部署到生产环境前的测试，代码是准生产版本，数据库是生产环境的。

• production：生产环境，代码、数据库都是生产环境的。

以上环境的代码稳定版依次提升。

3、分支种类

为配合以上几种部署环境，代码库分如下几种类型的分支：

• staging 分支：用于 staging 环境的部署。

• master 分支：GIT 的默认分支，提供最新、稳定的代码。

• preview 分支：用于 preview 环境的部署。

• release 分支：用于 production 环境的部署，保持代码随时可发布到生产环境。

以上几个分支会永久存在于代码库中，在开发功能、修复 BUG 的过程当中，还会用到几种分支。
开发新功能时会用到的：

dev 分支：以 dev_xxx 命名。xxx 表示**功能**的简单描述。

feature 分支：以 feature_xxx 命名，其中，xxx 表示对**子功能**的简单描述。
一个功能会拆成若干个子功能，每一个 RD 开发 1 个子功能。dev 分支与 feature 分支的区别：
一个新功能一般须要多个 RD 参与开发。RD 在各自的 feature 分支提交代码。存在一种状况，RD B 的代码
依赖 RD A，而这个时候两我的写的代码都不稳定，不适合往 master 分支合并。此时，RD A 将本身的代码
先合入 dev 分支，RD B 基于 dev 分支进行开发。

修复常规 bug 时会用到的：
bugfix：以 bugfix_xxx 命名。xxx 表示 bug 的简单描述。

修复紧急 bug 时会用到的：
hotfix：以 hotfix_xxx 命名。xxx 表示 bug 的简单描述。

综上，通常状况，咱们一共会用到如下几种分支： staging、master、preview、release、dev、feature、bugfix、hotfix 。

 

4、分支的生命周期

示意图

master 分支

默认存在，master 分支上保持最新的、稳定的代码。
从如下分支合并（merged from）：
dev、bugfix、hotfix

preview 分支

从如下分支合并（merged from）：
master
合入如下分支：
一旦拉出，再也不合入其它分支
说明：
preview 分支用于代码部署到生产环境前的预发布，用于正式上线前的最后一次测试。master 分支的代码部署到生产环境前，
先用 merge （发 merge request 或用 git merge 命令，下同）把代码合入 preview 分支。

release 分支

从如下分支合并（merged from）：
master
合入如下分支：
一旦拉出，再也不合入其它分支
说明：
preview 分支的代码在预生产环境测试经过后，master 分支上、合入 preview 分支的结点，往 release 分支 merge 一次。

staging 分支

从如下分支合并（merged from）：
feature
合入如下分支：
一旦拉出，再也不合入其它分支
 
说明：
 
staging 分支的代码给 RD 测试功能用。RD 在 feature 开发完子功能后，把代码提交到 feature 分支，再把 feature 分支合到 staging 分支。最后在 xbox 上部署 staging 环境，进行测试。

dev 分支

 派生自如下分支（forked from）： master
合入如下分支： master
说明：
dev 分支用于多人开发同一个功能时提交代码。它的存在时间跟新功能开发的时间相同。新功能开始开发时，它从 master 分支 fork 出来；新功能开发结束时，它被合入 master 分支，而后删除。

feature 分支

派生自如下分支（forked from）：
dev
合入如下分支：
staging、dev

说明：
feature 分支用于 RD 我的提交代码。开发新功能时，每一个 RD 从 dev 分支 fork 出本身的 feature 分支，不一样 RD 在远程代码仓库不共享 feature 分支。当代码可测试时，先提交到 feature 分支，再 merge 到 staging 分支、发布、测试。测试经过后，merge 到 dev 分支。若是另一个 RD 须要依赖你的代码，他须要先将本身 feature 分支 rebase （用 git rebase 命令）到最新的 dev 分支（包含你的代码），而后进行开发。

bugfix 分支

派生自如下分支（forked from）：
master
合入如下分支：
staging、master

说明：
bugfix 分支用于修复常规、不紧急的 bug。RD 开始修复 bug 时，从 master 分支 fork 出 bugfix 分支。提交修复代码后，把 bugfix 分支 merge 到 staging，在 staging 环境发布、测试。测试经过后，再把 bugfix 分支 merge 到 master，而后删除。

hotfix 分支

派生自（forked from）：release
合入如下分支：staging、master、preview、release

说明：
hotfix 分支用于修复生产环境的、紧急的 bug。RD 开始修复紧急 bug 时，从 release 分支 fork 出 hotfix 分支。提交修复代码后，把 hotfix 分支 merge 到 staging，在 staging 环境发布、测试。在 staging 测试经过后，再把 hotfix 分支 merge 到 preview，在 preview 环境进行测试。测试也经过后，再 merge 到 master、release 分支。

5、典型场景举例

下面举例一些常见场景，以及分支的操做步骤。

开发新的功能

一、某 RD 先从 master 分支 fork 出 dev 分支，命名为 dev_xxx 。
二、参与开发这个功能的 RD 基于 dev_xxx 分支 fork 出 feature_xxx_RDA，feature_xxx_RDB 等分支。
三、各 RD 在本身的 feature 分支开发子功能。
四、RD A 在本身的分支 feature_xxx_RDA 上提交了几个工具类，这些类会给其余 RD 用。他把 feature_xxx_RDA push（用 git push 命令）到远程仓库，再 merge 到 staging，在 staging 环境发布、测试。若是测试发现问题，他再提交一个 commit 到 feature_xxx_RDA 分支，而后 merge 到 staging，再发布、测试。测试经过后，他把 feature_xxx_RDA merge 到 dev_xxx 分>支，而后继续开发其它功能。
五、RD B 的工做依赖 RD A 开发的工具类。他把 feature_xxx_RDB rebase 到 最新的 dev_xxx 分支，而后进行开发。
六、全部 RD 开发完后，某 RD 再把 dev_xxx 分支 merge 到 master 分支，而后删除 dev_xxx 分支。
某 RD 再把 master 分支 merge 到 preview 分支。
七、在 preview 测试经过后，再把 master 分支 merge 到 release 分支，而后发布到生产环境。

修复常规 bug

一、某 RD 领到一个 bug。开始修复时，他从 master 分支 fork 出 bugfix 分支，命名为 bugfix_xxx 。
二、RD 在 bugfix_xxx 分支上提交修复代码，本身测试经过后，merge 到 staging，而且在 staging 
环境发布、测试。若是测试发现问题，他再提交一个 commit 到 bugfix_xxx 分支，而后再 merge 
到 staging，再发布、测试。直到测试彻底经过，他把 bugfix_xxx merge 到 master 分支，而后删除 bugfix_xxx 分支。
三、由于是常规 bug，他不须要立刻把修复的代码部署到生产环境。等待下一次发布周期便可。

修复线上紧急 bug

紧急 bug 是指若是不立刻修复，会形成重大损失的 bug。操做步骤以下：

一、某 RD 领到一个紧急 bug。开始修复时，他从 release 分支 fork 出 hotfix 分支，命名为 hotfix_xxx。
二、RD 在 hotfix_xxx 分支进行修复。提交代码后，他把 hotfix_xxx merge 到 staging，而且在 staging 环境发布、测试。若是测试发现问题，他再提交一个 commit 到 hotfix_xxx 分支，而后再 merge 到 staging，再发布、测试。直到测试彻底经过，他把 hotfix_xxx merge 到 preview 分支，在 preview 环境测试。若是测试发现问题，继续在 hotfix_xxx 分支提交修复代码，再 merge 到 staging 进行测试。
三、preview 环境测试经过后，RD 把 hotfix_xxx merge 到 release 分支。上线，在生产环境观察 bug 是否修复。
四、若是生产环境还有问题，继续在 hotfix_xxx 修复，而后在 staging、preview 测试，测试经过再从新上线。这种状况应该尽量**避免**，保证一次上线修复成功。
五、生产环境验证没问题后，RD 把 hotfix_xxx merge 到 master，而后删除 hot_xxx 分支。

建议：请勿在周五发布任何正式环境分支，以避免出现问题.

6、分支命名的建议

master、release、staging、preview 分支以它类型名字命名。
推荐的命名方式
对 dev 分支，建议以 dev_xxx_时间戳，其中，xxx 表示功能的英文简单描述，多个分词间用下划线分隔，时间戳用 yyyyMMdd 格式。如“保险礼品后台”功能的开发分支，可命名为 dev_ins_gift_20170329。
对 feature、bugfix、hotfix 分支，建议以 前缀_xxx_姓名 命名，其中前缀指 feature、bugfix、hotfix，xxx 表示功能的简单描述，姓名是负责开发功能的 RD 名字拼音。如修复链接数泄漏 bug 的分支，可命名为 bugfix_fix_conn_leak_zhangsan 。

反例

一、 不包含任何前缀
二、 只包含前缀、时间戳
三、 只包含前缀、姓名
四、 其它可读性低的命名

7、参考

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

http://nvie.com/posts/a-succe...

附录 名词解释

RD: Research and Development engineer，研发工程师