在Gitflow中处理发布分支

Question

我所在的公司使用了gitflow。

我们采用一个功能分支的方法，即实现、测试单个功能并将其合并到develop分支。当需要发布时，我们从develop创建一个release分支 - 我们在release分支上触发构建并将其部署到测试环境。由于多个功能分支已经合并到develop中，可能会出现一些集成缺陷。这些问题将直接在release分支上解决。一旦我们对release分支的状态感到满意，我们就会将（由QA签名的）完全相同的构建部署到生产环境。

此时，我们需要将发布分支代码返回到develop和master分支，这两个分支都是受保护的分支。假设在发布分支上有一些提交，我们需要进行2个PR，即将发布分支合并到develop和master分支。

几个问题：

1.人们如何直接审查针对发布分支的提交？我们可以在实际发布之前回退到develop，但我认为这似乎有些不合适。

2.人们如何处理将发布分支合并到develop和master分支？对develop的PR只包括直接针对发布分支进行的提交，而对master的PR还包括已经合并到develop中的所有功能。对master的PR似乎有点过时。

谢谢。

- Ryan.Bartsch

Answer 1

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

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

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

如果您从release创建功能分支并将其PR到release分支中进行正常的代码审查，那么当到了将release合并到另一个共享的Git Flow分支的时候，您可以确信release分支上的所有代码都已经过了代码审查，合并变得 routine merge，不需要进行深入审查。

许多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建议的那样使用--no-ff合并到master，但是知道您可以进行快进合并，可以确保合并后master的状态与您测试的release分支相同。如果您不这样做，则必须比较状态，以确保您没有忘记将hotfix合并回release或develop而使其覆盖master上的热修复。另一个小优点是，如果您连续有多个版本发布，则第一次出现hotfix时，您将首次将一堆旧的合并提交从master中合并到develop中，这有点令人困惑。

---

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

- TTT