Git Flow 分支模型

1.前言

Git Flow 模型（本文所阐述的分支模型）构思于 2010 年，也就是 Git 诞生后不久，距今已有 10 多年。在这 10 多年中，Git Flow 在许多软件团队中大受欢迎。

在这 10 多年里，Git 本身已经风靡全球，而使用 Git 开发的最流行的软件类型也更多地转向了网络应用。网络应用通常是持续交付的，不会回滚，也不需要支持多个版本的软件同时运行。这与原作者在 10 年前写这篇博文时所考虑的软件类型不同。

如果你的团队正在进行软件的持续交付，建议采用更简单的工作流程（比如 GitHub Flow），而不是试图把 Git Flow 强塞进你的团队。不过，如果您正在构建明确版本化的软件，或者您需要支持软件的多个版本，那么 Git Flow 可能仍然适合您的团队。

最后，请记住，一劳永逸式的通用解决方案是不存在的。考虑一下你自己的项目背景，再做决定。

2.Main branches 主要分支

在核心部分，开发模型受到了现有模型的极大启发。中心仓库拥有两个无限生命周期的主分支：

• master
• develop

每个 Git 用户对位于 origin 的 master 分支都不会陌生。与 master 分支平行的另一个分支叫 develop 分支。

我们把 origin/master 视为主分支，在这里，HEAD 的源代码总是反映生产就绪的状态。

我们认为 origin/develop 是主分支，HEAD 的源代码总是反映下一个版本最新交付的开发变更状态。有人称其为 “集成分支”。每晚的自动构建都是从这里开始的。

当 develop 分支中的源代码达到稳定点并准备发布时，所有变更都应以某种方式合并回 master 分支，然后标记上发布编号。具体做法将在后面讨论。

因此，每次将变更合并回 master 版本时，这就是一个新的生产版本。我们倾向于严格遵守这一点，因此理论上我们可以使用 Git 钩子脚本，在每次 master 版本有提交时自动构建软件并将其发布到生产服务器上。

3.Supporting branches 辅助分支

除了主分支 master 和开发分支 develop，我们的开发模式还使用各种辅助分支来帮助团队成员之间的 并行开发、简化功能跟踪、为生产发布做准备，以及 协助快速修复实时生产问题。与主分支不同，这些分支的生命周期总是有限的，因为它们最终会被移除。

我们可能使用的不同类型的分支包括

• Feature branches（特性分支）
• Release branches（发布分支）
• Hotfix branches（热修复分支）

每种分支都有其特定的目的，并受严格的规则约束，哪些分支可以作为其原始分支，哪些分支必须作为其合并目标。我们稍后将详细介绍它们。

从技术角度看，这些分支并不 “特殊”。分支类型是根据我们的使用方式来分类的。当然，它们都是普通的 Git 分支。

3.1 Feature branches 特性分支

来自于 develop，必须合并回 develop。

分支命名约定：只要不用 master，develop，release-*，hotfix-* ，其他都可以。

feature 分支（有时也称作主题分支 Topic branches）用于 为即将发布或未来发布的版本开发新特性。在开始开发某个功能时，可能还不知道该功能将被集成到哪个目标版本中。feature 分支的本质是，只要该特性还在开发阶段，它就一直存在，但最终会被合并回 develop（将新特性添加到即将发布的版本中）。

特性分支通常只存在于开发者版本库中，而不存在于原始版本库（origin）中。

（1）创建 feature 分支

开始开发新功能时，从 develop 分支创建分支。

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

（2）将已完成的功能并入 develop 分支

已完成的功能可以合并到 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

使用 - - no - ff 标志后，即使合并可以通过快进执行，也会始终创建一个新的提交对象。这样可以避免丢失 feature 分支历史存在的信息，并将共同添加该特性的所有提交组合在一起。

在后一种情况下，我们无法从 Git 历史记录中看到哪些提交对象一起实现了某个特性，而必须手动阅读所有日志信息。在后一种情况下，还原整个特性（即一组提交）确实是个令人头疼的问题，而如果使用 - - no - ff 标志，就很容易做到。

是的，这会多创建几个（空）提交对象，但收益远大于代价。

3.2 Release branches 发布分支

来自于 develop，必须合并回 develop 和 master。

分支命名约定：release-*。

release 分支支持新生产版本的准备工作。release 分支允许在最后一刻进行校验。此外，它们还可以进行小的错误修复，并为发布版本准备元数据（版本号、构建日期等）。在 release 分支上完成所有这些工作后，develop 分支就可以接收下一个大版本的功能了。

从 develop 分支分离出新版本分支的关键时刻是 develop 分支（几乎）反映了新版本的理想状态。至少所有针对即将发布的版本的功能都必须在此时合并到 develop 分支。而针对未来版本的所有功能则不一定，它们必须等到 release 分支分支化之后。

正是在 release 分支开始时，即将发布的版本才会被分配一个版本号，而不是更早。在此之前，develop 分支反映的是 “下一个版本” 的变更，但在 release 分支启动之前，“下一个版本” 最终是 $0.3$ 还是 $1.0$ 并不清楚。这个决定是在 release 分支启动时做出的，并由项目的版本号递增规则来执行。

（1）创建 release 分支

release 分支是从 develop 分支创建的。例如，$\mathrm{1.1.5}$ 版是当前的生产版本，而我们即将发布一个大版本。develop 分支已经为 “下一个版本” 做好了准备，我们决定将其命名为 $1.2$ 版（而不是 $\mathrm{1.1.6}$ 版或 $2.0$ 版）。因此，我们建立了分支，并给 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.
$ 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(-)

创建新分支并切换到该分支后，我们就会提升版本号。在这里，bump-version.sh 是一个虚构的 shell 脚本，它会更改工作副本中的某些文件，以反映新版本。(当然，这也可以是手动更改，关键是某些文件会发生变化）。然后，提交被修改的版本号。

这个新分支可能会存在一段时间，直到正式发布。在此期间，错误修复可能会应用到该分支（而不是 develop 分支）。严禁在此添加大型新功能。它们必须合并到 develop 分支，因此要等到下一个大版本发布。

（2）完成 release 分支

当 release 分支的状态准备好成为真正的发布版本时，需要执行一些操作。首先，将 release 分支合并到 master 分支（因为 master 分支上的每次提交都是一次新的发布，切记）。其次，必须对 master 分支上的提交进行标记，以方便将来引用这个历史版本。最后，需要将 release 分支上的修改合并回 develop 分支，以便未来的版本也包含这些错误修复。

Git 的前两个步骤：

$ 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

现在，发布工作已经完成，并打上了标签，以备将来参考。（你也可以使用 -s 或 -u <key> 标记对标签进行加密签名。）

为了保留 release 分支中的改动，我们需要把它们合并回 develop 分支。在 Git 中：

$ 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).

3.3 Hotfix branches 热修复分支

来自于 master，必须合并回 develop 和 master。

分支命名约定：hotfix-*。

hotfix 分支与 release 分支非常相似，都是为新的生产版本做准备，尽管是计划外的。它们产生的原因是，必须立即对实时生产版本中不希望出现的状态采取行动。当必须立即解决生产版本中的关键错误时，可以从标记生产版本的 master 分支上的相应标记中分出一个 hotfix 分支。

这样做的好处是，团队成员（在开发分支上）的工作可以继续进行，而另一个人则在准备快速的生产修复。

（1）创建 hotfix 分支

hotfix 分支是从 master 分支创建的。例如，$1.2$ 版是当前正在运行的生产版本，由于一个严重的错误而造成了很多麻烦。但开发中的更改还不稳定。这时，我们可以分离出一个 hotfix 分支，开始修复 $1.2$ 版本的错误。

$ 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(-)

分支后不要忘记提升版本号！

然后，修复错误并在一个或多个单独的提交中提交修复。

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

（2）完成 hotfix 分支

完成后，需要将漏洞修复合并回 master 分支，但同时也需要合并回 develop 分支，以确保下一个版本也包含该漏洞修复。这与 release 分支的完成方式完全类似。

首先，更新主版本并标记发布版本。

$ 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

可以使用 -s 或 -u <key> 标记对标签进行加密签名。

接下来，在 develop 中也包含错误修正：

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

这里的规则有一个例外，那就是当当前存在 release 版分支时，热修复程序的更改需要合并到 release 分支，而不是 develop 分支。将错误修正反向合并到 release 分支，最终会导致在 release 分支完成后，错误修正也被合并到 develop 分支。(如果 develop 中的工作立即需要这个错误修正，而又不能等到 release 分支完成，那么现在也可以安全地将错误修正合并到 develop 中）。

最后，删除临时分支：

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

4.总结

虽然这个分支模型并没有什么令人震惊的新内容，但这篇文章开头提到的 “全局” 图在我们的项目中却非常有用。它形成了一个优雅的心智模型，易于理解，并能让团队成员对分支和发布流程形成共识。