一. 结论

Github flow：最简单

小型项目，持续部署，自动化测试程度高，发布流程简单

Git flow：复杂但最常用

大型项目，发布周期长，需要同时维护多个版本，发布流程复杂

表格提供了不同情况下推荐采用的分支策略，帮助团队根据自己的特点和需求选择最合适的工作流程。

例如在自动驾驶软件开发中，软件生命周期长达 1-2 年，需同时维护多个平台的开发，需要经过严格的测试环节才能发布。所以会基于 git flow 做分支管理。

二. github-flow VS git-flow

1. Github Flow

多用于 Web 应用程序这种持续交付的项目模式，一般不必支持运行多个版本的软件

1.1 github-flow 框架

从图中可知, Github Flow 只有两个分支：

（1）Master(main): 主分支包含该项目的所有可直接用于发布部署的代码

（2）Feature: 开发人员直接从 main 分支出来开发新功能的分支

1.2 github-flow 工作流程

GitHub 就是采用 GitHub Flow 方式的，它的流程大致流程如下：

（1）在新项目开始时会创建一个空的主分支

（2）每个更改都直接从主分支分支切出来到功能分支

（3）一旦某个功能准备就绪，就会在功能分支进行测试，并对代码进行审查

（4）最后, 该功能被合并到主版本中，可以立即发布到生产环境中

1.3 github-flow 优缺点

1.3.1 优点

• 允许持续交付和部署

• 鼓励团队快速发布并获得有关他们所做工作的反馈

• 分支管理简单。除了 feature 分支外，几乎不需要任何分支管理

1.3.2 缺点

• 需可靠的自动化测试框架和自动化发布流程

• 不太适合多个开发人员需要并行开发的复杂功能

• 需要谨慎，因为合并到 main 中的任何错误都将直接进入生产

1.4 github-flow 适用情况

• 小型到中型项目：项目规模较小，功能模块较少，或者团队较小

• 持续部署：产品需要频繁更新，可能每天都有新的部署

• 简单的发布流程：发布流程简单，不需要复杂的测试和多环境部署

• 自动化测试：有成熟的自动化测试流程，可以快速验证代码质量

1.5 github-flow 举例（web 应用）

在一个小型的 Web 应用中，需频繁更新以修复 bug 或添加小功能。使用 GitHub Flow，你可以这样管理代码：

1. master 分支：始终处于可部署状态，是最新的稳定版本

2. feature 分支：为每个新功能或修复创建 feature 分支，从 master 拉取

3. Pull Request：完成开发后，发起 Pull Request，请求将 feature 分支合并回 master

4. Code Review：其他团队成员审查 Pull Request，提供反馈或批准

5. 自动化部署测试：Pull Request 提交后，自动运行测试，确保代码质量

6. Deployment：一旦 Pull Request 被批准且所有测试通过，合并回 master 并部署到生产环境

2. Git Flow

Git Flow 是最常用的分支管理策略

如果采用敏捷开发(Scrum)模式, 开发周期将围绕版本发布进行

此外，如果依靠 QA(质量保证) 在代码投入生产之前对其进行手动测试，这种情况下可以使用 Git Flow

2.1 gitflow 框架

如图所示, Git Flow 围绕多个分支工作。

（1）master 分支：用于存放稳定且发布版本的代码

（2）develop 分支：用于日常开发，所有新的功能分支都从这里开始

（3）feature 分支：为每个新功能创建的分支，完成后合并回 develop 分支

（4）release 分支：从 develop 分支创建，用于准备发布版本。当准备就绪后，会合并回 master 和 develop 分支

（5）hotfix 分支：从 master 分支创建，用于修复紧急问题，完成后合并回 master 和 develop 分支

2.2 gitflow 工作流程

（1）创建 main 分支. 对于新项目，首先创建一个主分支并保留为空，只保留 README.md 文件

（2）创建 develop 分支. 开发分支立即从主分支中切出来. 一般不会直接对 main 或 development 进行任何更改

（3）创建 feature 分支. 开发人员将从 develop 切出一个分支来进行更改

（4）将 feature 分支合并到 develop 分支. 在 feature 分支更改完成后，创建 (PR)，并对其进行审查, 对冲突进行修改

（5）创建发布分支. 一旦 feature 合入 develop 完成，将从 develop 分支切出来 release 分支。然后质量检查团队会在该版本准备好投入生产之前对其进行测试。与此同时，开发人员可以继续在 develop 分支上开发下一个版本的功能

（6）正式发版. 发版通常要么从 release 分支创建，要么在 release 分支合并到 main 分支后从 main 创建。如果您从 main 发布，则存在您发布的内容与 QA 测试的内容不同的风险

（7）如果发现 release 的发行版存在问题，通常会在 main 分支上创建一个分支来进行修复

2.3 gitflow 优缺点

2.3.1 优点

• 并行处理。允许并行处理多个版本

• 易于跟踪。提供清晰的版本控制，每个版本都经过标记并单独测试

• 允许多个开发人员开发同一功能。既可以交替提交半成品，又可以基于 feature 分支再次拉取分支开发

• 容易切换。允许在当前版本和未来版本的工作之间跳转，因为它们位于不同的分支路径上

2.3.2 缺点

• CICD不友好。不适合持续交付或持续部署

• 维护困难。许多分支需要维护，经常要将分支做合并, 以保证保持一致性

• 工作量大。由于发布工作较重，技术人员有不少工作量

2.4 gitflow 适用情况

• 大型项目：项目规模较大，功能模块多，需要协调多个团队或多个发布周期。

• 长期发布周期：产品发布周期较长，可能几周或几个月发布一次正式版本。

• 需要维护多个版本：需要同时维护多个版本的软件，例如稳定版、测试版和开发版。

• 复杂的发布流程：发布流程复杂，涉及到多个阶段的测试和多个环境的部署。

2.5 gitflow 举例（大型桌面应用）

假设开发一个大型的桌面应用程序，该程序每季度发布一个新版本。使用 Git Flow，你可以这样管理代码：

1. main 分支：保持最新稳定版本，仅用于发布

2. develop 分支：日常开发的基础，所有新功能都从这个分支开始

3. feature 分支：开发新功能时，从 develop 创建 feature 分支，完成后合并回 develop

4. release 分支：准备发布新版本时，从 develop 创建 release 分支，进行最后的测试和修改

5. hotfix 分支：当需要紧急修复线上问题时，从 master 创建 hotfix 分支，修复后合并回 master 和 develop

三. 参考资料

1. git flow

2. GitHub flow

3. A successful Git branching model

4. Git Flow vs GitHub Flow