Git 分支策略

Git 评论

常驻分支（主分支）

1
2
master 分支
develop 分支

master 分支

即是 Git 默认主分支，只用来发布重大版本，是生产环境出于准备就绪状态的最新源码分支。需要对此分支进行严格的控制，可以为每次 master 分支的提交都挂一个钩子脚本，向生产环境自动化构建并发布我们的软件产品。

develop 分支

develop 分支作为日常开发分支，可以理解为准备下一次发布的，开发人员最后一次提交的源码分支，这个分支也叫做 集成分支，此分支也作为每日构建（nightly build）自动化任务的源码分支

临时分支（支持型分支）

1
2
3
feature 功能开发分支（也叫 topic 分支）
release 预发布分支
hotfix 修补 issue 分支

这些分支是为了准备发布新产品，开发新的功能特性，快速或者紧急修复上线等任务而设立的分支，这些分支都是临时的，使命完成后，都应该删除。

release 分支

1
2
3
派生自：develop 分支
需要合并回：develop 或者 master 分支
分支命名规范：release-版本号

release 分支派生自 develop 分支。假设，当前的生产环境发布的版本（ mster 分支）是 1.1，我们确定新的版本号为 1.2 。通过下面命令派生一个新的 release 分支并以新的版本号为其命名：

1
2
$ git checkout -b release-1.2 develop
$ git commit -a -m "Bumped version number to 1.2"

这个新的 release 分支，从创建到发布出去会存在一段时间，在此期间，可能会有issue修复（bug 修复直接在 release 分支上进行）分支，完成后并入 develop 分支，并放入下一次发布。
release 分支真正发布成功后，还有下面的事要做：

1
2
3
4
5
6
7
8
9
10
11
// release 分支合并到master
$ git checkout master
$ git merge --no-ff release-1.2
// 在 master 分支上的打一个 tag，作为标签以便作为版本历史的参考
$ git tag -a 1.2
// release 分支产生的改动合并回 develop，以便后续的发布同样包含对这些 bug 的修复
$ git checkout develop
// -no-ff 标记使得合并操作总是产生一次新的提交，避免所有提交的历史信息混在一起
$ git merge --no-ff release-1.2
// 至此 release 分支使命已经完成，应该删除它
$ git branch -d release-1.2

feature 分支

1
2
3
派生自：develop 分支
需要合并回：develop
分支命名规范：feature-功能特性编号

feature 分支是用来开发即将发布的新的功能特性。feature 分支的生命周期会和新功能特性的开发周期保持同步，但是最终会合并回 develop 分支或被抛弃(功能特性不需要了)。
feature 分支通常仅存在于开发者的代码库中，并不出现在 origin 里。

1
2
3
4
5
6
7
8
9
// 从 develop 派生出 feature 分支
$ git checkout -b feature-12345 develop
...
// 功能开发完成后，合并回 develop 分支
$ git checkout develop
$ git merge --no-ff myfeature
// feature 分支使命完成，应该删除
$ git branch -d myfeature
$ git push origin develop

hotfix 分支

1
2
3
派生自：master 分支
需要合并回：develop 和 master
分支命名规范：hotfix-issue编号

hotfix 分支 是在实时的生产环境版本出现意外需要快速响应时，从 master 分支相应的 tag 被派生出来。这样做的原因，是为了让团队其中一个人来快速修复生产环境的问题，其他成员可以按工作计划继续工作下去而不受太大影响。
假设，当前 master 版本是1.2 ，生产环境出现了较严重的 issue (假设，记录 bug 编号为 10002)，此时就要从 master 分支派生一个 hotfix 分支：
` bash
// 从 master 派生出 hotfix 分支
$ git checkout -b hotfix-10002 master
…
// 修复 bug，提交代码
$ git commit -m “Fixed severe production problem”
// bug 修复完成后，hotfix 分支需要并回 master 和 develop 分支，以保证接下来的发布也都已经解决了这个 bug
$ git checkout master
$ git merge –no-ff hotfix-10002
// 变更小版本号
$ git tag -a 1.2.1
$ git checkout develop
$ git merge –no-ff hotfix-10002
// hotfix 分支使命完成，应该删除
$ git branch -d myfeature

下图形象的总结了以上分支之间的派生关系

本文是阅读了A successful Git branching model之后的自我总结。