其他 Git 工作流

Gitflow 仍然是最流行的工作流之一。它是在 2010 年由 Vincent Driessen 引入的（见：https://nvie.com/posts/a-successful-git-branchingmodel/），并且迅速变得非常流行。Gitflow 有一张非常漂亮的海报，并且提供了一个非常清晰的解决方案，来处理 Git 中的各种问题，例如使用标签发布和使用合并后会被删除的分支（见图 11.1）：

Gitflow 非常适合于那些每隔几个月才发布软件，面向不同客户，并希望将一些特性打包成一个新的大版本（通常是按单独许可证进行发布），并且需要维护多个版本的情况。2010 年，这几乎是所有软件的常见发布流程，但在复杂的环境中，这个工作流会带来一些问题。

该工作流不是基于主干（trunk-based）的，并且有多个长期存在的分支。这些分支之间的集成可能导致复杂环境下的“合并地狱”（merge hell）。随着 DevOps 和 CI/CD 实践的兴起，这种工作流的声誉开始变差。

如果你希望通过 DevOps 加速软件交付，Gitflow 可能不是最适合的分支工作流！但是，许多概念可以在其他工作流中找到。

GitHub Flow 非常注重通过拉取请求（PR）进行协作。你会创建一个有描述性名称的分支并进行首次更改。接着，创建一个 PR，并通过对代码的评论与评审者进行协作。当 PR 准备好后，它会被部署到生产环境中，然后再合并到主分支（见图 11.2）。

GitHub Flow 是基于主干（trunk-based）的，并且非常流行。其基本部分——没有 PR 部署的部分——是大多数其他工作流的基础。问题在于部署。将每个 PR 部署到生产环境会造成瓶颈，且不太适合大规模扩展。GitHub 本身使用 ChatOps 和部署火车（deploy trains）来解决这个问题（Aman Gupta, 2015），但我认为这有些过度设计。虽然只有经过验证能在生产中正常工作的更改才会合并到主分支这一目标很有吸引力，但在复杂环境中，这个目标基本上无法实现。你需要相当长的时间才能确认这些更改是否在生产中正常工作，而在这个过程中，瓶颈阻碍了其他团队或团队成员合并他们的更改。

在 DevOps 环境中，遵循“快速失败”和“向前推进”的原则，我认为最好的做法是先在隔离环境中验证 PR，再在合并 PR 后通过主分支的推送触发器将其部署到生产环境。如果更改破坏了生产环境，你仍然可以部署上一个工作正常的版本（回滚），或者立即修复错误并将修复部署到生产环境（向前推进）。你不需要一个完全干净的主分支来执行这两种操作。

我对 GitHub Flow 另一个不太喜欢的地方是，它没有明确说明用户、分支和 PR 的数量。一个功能分支可能意味着多个开发者共同向同一个功能分支提交代码。尽管我并不常见这种情况，但从文档上看，它并不十分明确。

Release Flow 基于 GitHub Flow，但与持续部署 PR 不同，它增加了单向的发布分支。这些分支不会被合并回主分支，且 bug 修复遵循“上游优先”原则：它们首先在主分支上修复，然后通过 cherry-pick 操作将更改应用到发布分支（Edward Thomson, 2018）。通过这种方式，无法忘记将 bug 修复应用到主分支（见图 11.3）。

Release Flow 不是持续部署（CD）！创建发布仍然是一个需要单独触发的过程。如果你需要维护不同版本的软件，Release Flow 是一个不错的做法。但如果可能的话，你应该尝试实现持续部署（CD）。

GitLab Flow 也基于 GitHub Flow，但它添加了环境分支（例如开发、预生产、生产等），每次部署发生在这些环境的合并时（见图 11.4）：

由于更改仅沿下游流动，你可以确保所有更改在所有环境中都经过测试。GitLab Flow 也遵循“上游优先”原则。如果在某个环境中发现 bug，你会创建一个主分支的特性分支，并将更改 cherry-pick 到所有环境中。Bug 修复在 GitLab Flow 中的工作方式与 Release Flow 中相同。

如果你没有支持多个环境的流水线（例如 GitHub Actions），GitLab Flow 可能是一个很好的方法来自动化你的审批和部署流程。个人而言，我不认为将环境代码分开有什么价值，尤其是在你反正会进行上游 bug 修复的情况下。我更倾向于只构建一次代码，然后按顺序将输出部署到所有环境。但在某些情况下，这种工作流可能有意义，例如对于直接从仓库部署的静态网站。