分支模型 Git Flow

思考

团队并行开发多个功能，这些功能有可能是跨版本，如何才能既保证跨版本的代码不影响当前版本、又保证跨版本功能的正常开发和协作？
生产环境发现严重 Bug 需要立即修复，而当前版本的代码已提交 master 分支、且并未测试充分，这时该如何处理？
交给你的新功能已经开发完毕，但最终删掉了这些新功能，如何才能将回退成本降到最低？

利用 Git 强大的分支，可以帮助我们很好的解决这些问题。

有个很成熟的叫 Git Flow 的分支模型，能够应对 99% 的场景。简单来说，Git Flow 就是给原本普普通通的分支赋予了不同的职责。

The main branches

master
develop

master 和 develop 被称为主分支（main branches）。

master 分支上的代码应该是可以随时发布生产环境的，即 “production-ready”。

develop 分支上的代码应该是 upcoming release 所需要的最新的代码，也称为 “integration branch”。

Supporting branches

为了做到 并行开发、跟踪新功能的开发、生产打包、快速修复线上Bug，还需要一些辅助分支（supporting branches）。

Feature branches
Release branches
Hotfix branches

辅助分支都是临时性的，最终都会被删除。

辅助分支从技术上来说，跟主分支没有任何区别，唯一的区别在于，我们赋予了它们不同的职责。

Feature branches

Branch off from:

develop

Merge back into:

develop

Branch naming convention:

除了 master, develop, release-, or hotfix- 都可以，最好是 **feature-***

Feature branches 有时也称为 Topic branches，用来开发新功能，在创建时可能并不清楚该功能属于哪次发布版本。

创建 Feature 分支：

$ git checkout -b myfeature develop

如果新功能属于 upcoming release，开发完成后需要将其合并到 develop 分支：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

Release branches

Branch off from:

develop

Merge back into:

develop and master

Branch naming convention:

**release-***

当 upcoming release 所包含的新功能已全部开发完成、且达到稳定状态（测试通过）时，就可以从当前 develop 分支创建新的 Release 分支，用于发布生产环境。

Release 分支只允许进行小的 Bug 修复以及一些元信息（meta-data ）的修改，比如版本号、构建时间等，原则上不允许再进行新功能的开发。

将用于发布生产的 Release 分支一旦创建，就代表着 develop 分支可以接受 next release 所包含的新的 Feature 分支的代码合并了。

创建 Release 分支：

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2. This can of course be a manual change
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

当 Release 分支已经达到发布要求时，需要将其合并到 master 和 develop 分支。

合并到 master 分支，同时打 tag：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

合并到 develop 分支（可能会包含 bug fixes 代码和更新后的 meta-data）：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

发布验证成功后，删除 Release 分支：

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches

Branch off from:

master

Merge back into:

develop and master

Branch naming convention:

**hotfix-***

当生产环境出现严重 Bug、需要立即修复时，就需要从 master 分支对应的线上 tag 检出 Hotfix分支、进行 Bug 修复。

创建 Hotfix 分支：

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

解决 Bug、提交代码：

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

跟 Release 分支一样，最后需要将 Hotfix 分支合并到 master 和 develop 分支：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

特别注意，当存在 Release 分支时，需要将 Hotfix 分支合并到 Release 分支而不是 develop 分支。

首先 Release 分支上是即将发布生产环境的代码、需要包含这次修复Bug 的内容；其次 Release 分支在发布生产环境后、最终还是要合并到 develop 分支。

如果 develop 分支急需这些修复 Bug 的内容、无法等待 Release 发布，也可以立即将 Hotfix 立即合并到 develop 分支。

发布验证成功后，删除 Hotfix 分支：

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

Summary

References

git-flow cheatsheet Issues with git-flow gitflow consider harmful

mambat / blog