是的,另一个git流问题.. 🙁

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

>开发人员从上游分支(比如’master’)创建跟踪分支(比如’featureA’)
>开发人员代码,提交,带有rebase的代码,代码,提交,带有rebase的拉动等
>代码完成后,开发人员压缩提交并推送到掌握

我遇到的问题是,在与主服务器合并之前,没有留下代码审查的余地.审阅者只有在主数据库上才会看到更改,因此如果开发人员需要调整任何内容,则主数据库中将针对给定功能进行多次提交.理想情况下只有一个.

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

>让开发人员将功能分支推送到远程.这个问题是,在他们从主人那里重新推出后,推动必须是一个推力,虽然在这种情况下可能是安全的,但我并不像往常一样.
>不要将上游更改重新绑定到功能分支,合并它们.有了这个我不能压缩功能分支并将提交推回到主(右??)
>使用gerrit / github.我必须猜测,有一种方法可以在纯git中实现这一点吗？

有没有更好的办法？

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

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

>开发人员提交到功能分支.完成后,他将功能分支压缩并将其重新绑定到当前主设备上.
>代码审查软件禁止直接推入主分支,因此开发人员然后将该功能(压缩到一个提交)推送到审查系统,在那里可以审查它. Gerrit透明地处理每个审核请求,作为合并的单独分支(樱桃选择也是可能的,但不是默认的),当审核完成时.
>如果更改未通过代码审查,则开发人员可以修改提交并将提交重新推送到审阅系统.该软件重新确认多个(修改的)提交是否属于同一个功能审查请求.当审查最终完成时,只有最新的提交合并到实际的主分支中.
当然,由于每个功能只是一次提交,因此无法跟踪开发人员在代码审查期间执行的调整(但是,据我所知,这实际上是需要的).然而,每个审核请求的历史都由Gerrit管理,因此没有真正丢失.

我们仍在评估与此类似的工作流程,但尚未在生产中使用它.因此,我不能就这种方法在现实场景中的实际效果做出任何陈述.但我的观点是,如果您对使用Git的更复杂的审阅工作流程感兴趣,Gerrit可能值得一看.