何时在 Git Flow 中请求代码审查？

Question

在我的公司，我们最近开始使用 gitflow 来管理我们的分支机构，我的疑问是：应该在什么时候进行代码审查？

简单的 gitflow：

假设我们有这些已打开的拉取请求：

• 功能/新页面 -> 开发
• 开发->发布
• 发布->主

我们是否需要对所有这些拉取请求进行代码审查？只有合并功能时才能开发？等等...？

Answer 1

当这些条件两个都成立时，您应该进行正式代码审查（在本例中为拉取请求）：

1. base（或target）分支是 Git Flow 共享分支之一。 （例如

   develop

   、

   release/*

   、

   hotfix/*

   、

   main

   ）
2. source 分支不是 Git Flow 共享分支之一。 （例如功能分支）

至于如何执行标准的 Git Flow 合并，例如

release

到

main

、

main

到

develop

等，您也可以使用 PR 功能来实现此目的，但它们不需要正式的代码审查，因为所有正在合并（应该）的代码都已经过代码审查，以便进入共享的 Git Flow 分支。不过，您可能仍然希望进行健全性检查，如果您有任何门控签入，那么让它们运行以确保合并不会产生一些意外的副作用也没什么坏处。最终您可能希望自动化这些合并，但是，即使您确实自动化它们，当存在冲突时您仍然需要偶尔手动执行它们。 （将

release

/

main

合并到

develop

通常会发生冲突。）

Answer 2

我的公司目前正在问这个确切的问题。我是从保持开发分支清除功能问题的角度来看待它的。我的建议是将起源/发展纳入功能中。然后对功能分支进行审查，如果一切正常，我们会将更改带回到原始/开发中。如果审核失败，请继续开发该功能。我正在考虑将功能工作排除在开发之外，以保持功能并行运行。 @Arthur，你的公司最后怎么样了？