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

Question

，这是另一个混​​帐流问题.. :(

我知道了“标准” git的变基流非常好：

• 开发人员创建一个跟踪分支（说“featureA”）关闭上游分支（说“主”）
• 开发代码，提交与底垫，码拉，提交与底垫拉等
• 代码完成，开发商南瓜提交和推动掌握

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

，我知道会解决这个问题，但都不理想

有几个选项：

• 有开发商推特性分支到遥控器。与此相关的问题是，他们从主人重新启动后，推动将不得不是推力，虽然可能安全这种情况下，我不想像往常一样生意。
• 不要重新绑定功能分支的上游更改，将它们合并。有了这个，我不能挤压功能分支，并将提交回推给主（右？）
• 使用gerrit/github。我必须猜测，有一种方法可以在纯粹的git中实现这一点？

有没有更好的方法？

Answer 1

有一些第三方工具允许更复杂的审查工作流程。我们目前正在评估基于Gerrit的工作流程。

一个可能的格里特工作流程看起来是这样的：

• 开发人员提交到一个特性分支。完成后，他压缩功能分支并将其重新绑定到当前主设备上。
• 代码审查软件禁止直接推入主分支，因此开发人员会将该功能（压扁到一个提交）推入审查系统，以供审查。 Gerrit在审查完成后以透明的方式将每个审核请求作为一个独立的分支进行处理（樱桃选择也是可行的，但不是默认的）。
• 如果发生变化而不是通行代码审查，开发人员可以修改提交并重新提交到审查系统。如果多个（修改）提交属于同一个特征查看请求，软件会重新识别。审查终于完成时，只有最新的提交被合并到实际的主分支中。
  当然，由于每个功能只有一次提交，因此无法追踪开发人员在代码审查期间执行的调整（但是，据我了解，这实际上是需要的）。然而，每次审查请求的历史由Gerrit管理，所以没有任何事情真的丢失。

我们仍在评估类似于此的工作流程，但尚未在生产中使用它。所以我无法对这种方法在真实世界中的实际运行情况做出任何声明。但我的观点是，如果你有兴趣与Git的更为复杂的审核工作流程，格里特可能是值得一试。

Answer 2

与此工作流程的最大的问题是有壁球一个承诺。这是Gerrit的限制。 CodeCollaborator解决了这个问题，并允许多个提交，我们更喜欢。