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

Question

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

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

• 开发人员从上游分支（比如“master”）创建一个跟踪分支（比如“featureA”）
• 开发人员代码、提交、rebase 拉取、代码、提交、rebase 拉取等
• 代码完成，开发人员压缩提交并推送到掌握

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

我知道的一些选项可以解决这个问题，但并不理想：

• 让开发人员将功能分支推送到远程。问题在于，在他们从 master 重新定位后，推送必须是强制推送，虽然在这种情况下可能安全，但我不想照常营业。
• 不要将上游更改重新设置为功能分支，而是合并它们。有了这个，我无法压缩功能分支并将提交推回主节点（对吗？？）
• 使用gerrit/github。我不得不猜测有没有办法在纯 git 中实现这一点？

有没有更好的办法？

Answer 1

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

一种可能的 Gerrit 工作流程可能如下所示：

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

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