带有代码审查的 git rebase 流程？可能的？

Question

是的，另一个 git 流程问题.. :(

我非常了解“标准”git rebase 流程:

• 开发人员从上游分支(比如“master”)创建一个跟踪分支(比如“featureA”)
• 开发人员代码、提交、使用 rebase pull 、代码、提交、使用 rebase pull 等
• 代码已完成，开发人员压缩提交并推送给 master

我遇到的问题是，这在与 master merge 之前没有代码审查的余地。审阅者仅在母版上看到更改，因此如果开发人员需要调整任何内容，将针对给定功能在母版上进行多次提交。理想情况下只有一个。

我知道有几个选项可以解决这个问题但并不理想:

• 让开发人员将功能分支推送到远程。这样做的问题是，在他们从 master 重新定位之后，推送必须是强制推送，虽然在这种情况下可能是安全的，但我不想像往常一样。
• 不要将上游更改 rebase 到功能分支，而是 merge 它们。有了这个我就不能压缩功能分支并将提交推回主服务器(对吗？？)
• 使用 gerrit/github。我不得不猜测是否有一种方法可以在纯 git 中实现这一点？

有没有更好的办法？

Answer 1

有一些第 3 方工具可以实现更复杂的审核工作流程。我们目前正在评估基于 Gerrit 的工作流程.

一个可能的 Gerrit 工作流程如下所示:

• 开发人员提交功能分支。完成后，他压缩功能分支并将其 rebase 到当前主分支上。
• 代码审查软件禁止直接推送到 master 分支，因此开发人员随后将功能(压缩为一次提交)推送到审查系统，以便对其进行审查。 Gerrit 透明地将每个审查请求作为一个单独的分支处理，并在审查完成后 merge (也可以 cherry-pick ，但不是默认的)。
• 如果更改没有通过代码审查，开发人员可以修改提交并将提交重新推送到审查系统。该软件会识别多个(修改后的)提交是否属于同一功能审查请求。当review最终完成时，只有最新的commit被 merge 到实际的master分支中。
  当然，由于每个功能都只是一次提交，因此不可能跟踪开发人员在代码审查期间执行的调整(但是，据我了解，这实际上是需要的)。但是，每个审核请求的历史记录都由 Gerrit 管理，因此不会丢失任何内容。

我们仍在评估与此类似的工作流程，但尚未在生产中使用。因此，我无法就这种方法在现实场景中的实际效果发表任何声明。然而，我的观点是，如果您对使用 Git 进行更复杂的审查工作流程感兴趣，Gerrit 可能值得一看。