在 gitflow 中处理发布分支

Question

我工作的公司正在使用 gitflow。

我们遵循每个功能分支的方法，其中实现、测试各个功能，然后 PR'd 到开发中。 当需要发布时，我们会在开发之外创建一个发布分支——我们会在发布分支上触发构建并将其部署到测试环境中。 由于合并到开发中的多个功能分支，可能存在一些集成缺陷。 这些直接针对发布分支解决。 一旦我们对发布分支的 state 感到满意，我们就会将其部署（与 QA 签署的完全相同的构建）到 PROD。

在这个阶段，我们需要让我们的发布分支代码回到 develop 和 master，这两个都是受保护的分支。 假设有一些针对发布分支的提交，我们需要做 2 个 PR，即一个用于 release->develop，一个用于 release->master。

几个问题：

1. 人们如何审查直接针对发布分支的提交？ 我们可以在实际发布之前通过 PR 进行开发，但这对我来说似乎有点不合时宜。
2. 人们如何将发布分支合并到 develop AND master 中。 develop 的 PR 只是直接针对发布分支进行的提交，而 master 的 PR 还将包括已经 PRd 到 develop 中的所有功能。 PR to master 似乎有点过时了。

谢谢。

Answer 1

tl;dr：理想情况下，执行例行 Git Flow 分支合并时不需要代码审查。 相反，您将确保对 Git Flow 共享分支的所有提交都经过代码审查。 请注意，此解决方案回答了您的两个问题。

详细信息：在您的示例中，将release合并到master或将release合并到develop （理想情况下）不需要人工干预，理论上可以自动化¹ 。 不过，为了实现这一点，您确实需要对 go 到release的所有提交进行代码审查，这意味着您需要调整工作流程的这一部分：

由于合并到开发中的多个功能分支，可能存在一些集成缺陷。 这些直接针对发布分支解决。

如果您从release创建功能分支并通过正常的代码审查将它们 PR 到release分支，那么稍后当需要将release合并到另一个共享 Git Flow 分支时，您可以放心， release分支上的所有代码都已经是代码经过审查，合并成为常规合并，不需要进行深入审查。

许多 Git SCM 工具都有受保护分支的概念，需要使用 PR 才能将代码合并到其中。 这里的建议是除了保护develop和master之外，你还应该保护你的release和hotfix分支。

提示：在完成release分支时， Git Flow 建议将release分支合并到master和develop中。 然而，有一种稍微更有效的机制可以实现相同的state ，但有一些额外的优势。 调整是先将release合并到master ，然后再将master合并到develop 。 这样做的好处是master上的新合并提交也将在develop上，这意味着develop比master “领先”。 当需要将下一个release分支合并到master时，从提交 ID 的角度来看，它将完全是最新的，这意味着您可以进行快进合并。 当然，您仍然会像 Git Flow 推荐的那样使用--no-ff合并到master中，但是知道您可以快进可以肯定地告诉您合并后master的 state 与您测试的release分支相同。 如果您不这样做，则必须比较状态以确保您不会破坏您忘记合并回release或develop的master上的修补程序。 另一个小好处是，如果不这样做，如果您连续发布了多个版本，那么第一次进行hotfix时，您将第一次将一堆旧的合并提交从master合并到develop中，这有点令人困惑看到那个。

---

¹ Git 流共享分支合并通常可以自动完成。 只有在存在非确定性合并冲突的情况下，人才需要介入。 不确定性冲突的一个例子可能是将release或master向下合并到develop时，在创建release分支后，两个分支中的某些文件都发生了变化。 请注意，某些冲突可能被认为是确定性的，并且仍然可以通过逻辑自动解决，例如在两个分支中修改的版本文件，并且解决机制是事先已知的。