我们正在考虑将Gerrit用于大型项目.在这一点上,了解人们如何处理已批准变更的合并冲突将会很有趣.
想象一下,不同大小的许多变化同时待修订,并且正在逐步审查和验证.由于其中一些可能正在修改同一段代码,因此冲突是不可避免的.如果"集成商"在简单的工作流程中手动接受补丁,则可以在途中解决小的冲突,但Gerrit的情况有所不同,这不是问题.当审查和批准变更时,如果合并冲突,我理解,它将需要由作者重新定位并再次推送进行修订,在这种情况下,修订过程将再次开始.在相对活跃的项目中,每周有超过50个外部贡献者提交,如果由于每次批准和提交后合并拒绝可能需要多次修改相同的补丁,这可能会变成噩梦,这似乎是效率不高.
问题:
我是否正确认为Gerrit不是一个前进的方式,因为预期会发生大量的合并冲突？
一些合并冲突可能是微不足道的,有没有办法解决它们而不需要打扰作者重新发生变化？
如果需要将更改反向移植到稳定分支,我想每个分支的单独更改需要推送进行修订,即使樱桃选择是干净的.
关于您的Gerrit工作流程体验的一般评论也是受欢迎的.
gerrit ×1