logo标签列表

使用代码审查的git rebase流程？可行吗？

git
5
是的，又是一个Git Flow的问题.. :(
我很了解"标准"的Git Rebase流程：
1. 开发者从上游分支（比如master）创建一个追踪分支（比如featureA） 2. 开发者编写代码，提交代码，在拉取最新代码时使用rebase，然后继续编写、提交、再次使用rebase进行操作等等 3. 完成编码，开发者将提交压缩并推送到master分支
我的问题在于这个流程没有留下任何空间用于与主分支合并之前的代码审核。评审人员只能在代码合并到主分支时才能看到更改。如果开发者需要对代码进行微调，则会对给定功能有多个主分支提交。理想情况下，只有一个。
我知道几种可以解决此问题但不理想的选项：
- 让开发者将功能分支推送到远程。这种方法的问题是，在他们从主分支rebase后，推送将不得不强制执行，虽然在这种情况下可能是安全的，但这不是我想要作为常规业务的事情。 - 不要将上游更改rebase到功能分支，而是将它们合并。使用此方法，我无法压缩功能分支并将提交推回主分支（对吗？） - 使用Gerrit/Github。但我猜想在纯Git中也有一种方法可以实现？
是否有更好的方法？
3个回答
2

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

可能的Gerrit工作流如下：

  • 开发人员提交到功能分支。完成后，他将功能分支压缩并重新基于当前主分支。
  • 代码审查软件禁止直接推送到主分支，因此开发人员将压缩为一个提交的功能推送到审查系统中进行审查。 Gerrit会透明地处理每个审查请求作为单独的分支，在审查完成时合并（cherry-pick也可以，但不是默认值）。
  • 如果更改未通过代码审查，则开发人员可以修改提交并将其重新推送到审查系统。软件会识别多个（修改后的）提交是否属于同一功能审查请求。最终完成审查后，仅将最新的提交合并到实际的主分支中。
    当然，由于每个功能只是一个单独的提交，因此无法跟踪开发人员在代码审查期间执行的微调（但是，据我所知，这实际上是需要的）。但是，每个审查请求的历史记录由Gerrit管理，因此实际上没有丢失任何信息。

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

谢谢helmbert，我实际上更新了我的问题 - 如果可能的话，我想做的一件事是不使用gerrit / github，主要是因为在我的组织中两者都不太可能被接受，不幸的是。虽然我确实喜欢gerrit的流程。 - Roy Truelove
1
这个工作流最大的问题是需要将所有提交压缩成一个提交。这是 Gerrit 的限制。CodeCollaborator 避免了这个问题，允许多次提交，这是我们更喜欢的方式。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接