使用Gitflow时如何处理PR？

Question

运行 Gitflow 时我应该进行多少次 PR 审查？我有一个功能分支，其中有很多更改。我已经通过评论对它进行了公关，并将其合并到开发分支中。在发布之前可能还剩下一两个小变化。当我将发布代码合并到主分支时，我是否应该进行另一次完整的 PR 审查。特别是因为大多数更改将与我在 PR 中从功能到开发中审查的内容相同，这似乎是浪费时间，而且以我目前的理解，如果我不在第二次进行审查从发布到主版本的公关，有些东西可能会被遗漏。您如何处理这种冗余，或者是否有某种行业标准方法？谢谢！

一个想法是，也许 PR 和他们的评论只是从功能到开发所必需的？

Answer 1

我们通过以下方式采用了 gitflow，这就是我们所做的：

1. 我们有多个微服务，每个微服务都有自己的存储库。
2. 我们使用 master 分支进行当前产品的下一个版本的开发。
3. 在主分支上开发的每个功能/错误修复都会得到适当的审查。
4. 一旦宣布发布，每个存储库都会从主分支的头部直接分支一个 release 分支。
5. 发布分支经过资格审查。 （完整的产品测试）。
6. 如果在发布分支上发现错误，则会生成修补程序。在发布分支上，修补程序经过正确的测试/审查，然后合并回主分支，我们在主合并期间不会再次进行彻底的测试，而是依赖于与该功能一起开发的自动化测试。
7. 如果我们在主分支上发现一个错误，并且我们知道它在发布分支上会是相同的错误，那么我们会独立地在两个分支上进行测试。因为我们希望确保修补程序仍然与分支兼容，因为它变得越旧，代码就会出现分歧。该修补程序通过cherry-pick方式传输到发布分支。

一个人想要/必须做的评论数量取决于许多不同的因素。有些是因为公司政策或行业规定，有些则取决于分支机构因老化而变化多少......等等。

我们尽量保持保守，但我们理解审核需要花费大量时间和精力。因此，我们尝试保持发布分支简短，例如在我们的例子中，假设大约 4 个月，我们会在新版本发布后立即更新已部署的产品。

一般来说，分支之间的差异越多，您可能就越需要关注合并。快进合并不需要额外的审查，因为它与已经测试过的代码相同。

顺便说一句，只有在必须维护多个发布分支时才需要使用 gitflow。