Git Flow 分支模型
1.前言
Git Flow 模型（本文所阐述的分支模型）构思于 2010 年，也就是 Git 诞生后不久，距今已有 10 多年。在这 10 多年中，Git Flow 在许多软件团队中大受欢迎。
在这 10 多年里，Git 本身已经风靡全球，而使用 Git 开发的最流行的软件类型也更多地转向了网络应用。网络应用通常是持续交付的，不会回滚，也不需要支持多个版本的软件同时运行。这与原作者在 10 年前写这篇博文时所考虑的软件类型不同。
如果你的团队正在进行软件的持续交付，建议采用更简单的工作流程（比如 GitHub Flow），而不是试图把 Git Flow 强塞进你的团队。不过，如果您正在构建明确版本化的软件，或者您需要支持软件的多个版本，那么 Git Flow 可能仍然适合您的团队。
最后，请记住，一劳永逸式的通用解决方案是不存在的。考虑一下你自己的项目背景，再做决定。
2.Main branches 主要分支
在核心部分，开发模型受到了现有模型的极大启发。中心仓库拥有两个无限生命周期的主分支：
masterdevelop
每个 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
0.3
0.3 还是
1.0
1.0
1.0 并不清楚。这个决定是在 release 分支启动时做出的，并由项目的版本号递增规则来执行。
（1）创建 release 分支
release 分支是从 develop 分支创建的。例如，
1.1.5
1.1.5
1.1.5 版是当前的生产版本，而我们即将发布一个大版本。develop 分支已经为 “下一个版本” 做好了准备，我们决定将其命名为
1.2
1.2
1.2 版（而不是
1.1.6
1.1.6
1.1.6 版或
2.0
2.0
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
1.2
1.2 版是当前正在运行的生产版本，由于一个严重的错误而造成了很多麻烦。但开发中的更改还不稳定。这时，我们可以分离出一个 hotfix 分支，开始修复
1.2
1.2
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 中）。
最后，删除临时分支：文章来源：https://www.toymoban.com/news/detail-644532.html
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
4.总结
虽然这个分支模型并没有什么令人震惊的新内容，但这篇文章开头提到的 “全局” 图在我们的项目中却非常有用。它形成了一个优雅的心智模型，易于理解，并能让团队成员对分支和发布流程形成共识。文章来源地址https://www.toymoban.com/news/detail-644532.html
到了这里，关于【CI/CD】Git Flow 分支模型的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
