在 gitflow 中处理发布分支

Question

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

我们遵循每个功能分支的方法，其中实现、测试单个功能，然后 PR 进入开发阶段。当需要发布时，我们会在开发之外创建一个发布分支 - 我们在发布分支上触发构建并将其部署到 TEST 环境。由于合并到开发中的多个功能分支，可能存在一些集成缺陷。这些是直接针对发布分支解决的。一旦我们很高兴与发布分支，我们部署（确切的状态同样是签署过建立由QA），以督促。

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

几个问题：

1. 人们如何直接针对发布分支审查提交？我们 可以在实际发布之前重新进行 PR 开发，但这对我来说似乎有点不合时宜。
2. 人们如何处理将发布分支合并到开发和主分支中的方法。要开发的 PR 只是直接针对发布分支进行的提交，而要掌握的 PR 还将包括已经 PRd 到开发中的所有功能。掌握的公关似乎有点过时了。

谢谢。

Answer 1

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

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

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

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

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

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

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