5

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

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

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

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

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

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

有没有更好的办法？

4

3 回答 3

2

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

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

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

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

于 2013-01-23T16:18:08.840 回答
1

这个工作流程的最大问题是必须压缩到一个提交。这是 Gerrit 的局限性。CodeCollaborator 解决了这个问题并允许多次提交，这是我们更喜欢的。

于 2013-01-24T02:15:06.897 回答