Gerrit修订工作流程:合并冲突和重新批准

Question

我们正在考虑将Gerrit用于大型项目.在这一点上,了解人们如何处理已批准变更的合并冲突将会很有趣.

想象一下,不同大小的许多变化同时待修订,并且正在逐步审查和验证.由于其中一些可能正在修改同一段代码,因此冲突是不可避免的.如果"集成商"在简单的工作流程中手动接受补丁,则可以在途中解决小的冲突,但Gerrit的情况有所不同,这不是问题.当审查和批准变更时,如果合并冲突,我理解,它将需要由作者重新定位并再次推送进行修订,在这种情况下,修订过程将再次开始.在相对活跃的项目中,每周有超过50个外部贡献者提交,如果由于每次批准和提交后合并拒绝可能需要多次修改相同的补丁,这可能会变成噩梦,这似乎是效率不高.

问题:

1. 我是否正确认为Gerrit不是一个前进的方式,因为预期会发生大量的合并冲突？

2. 一些合并冲突可能是微不足道的,有没有办法解决它们而不需要打扰作者重新发生变化？

3. 如果需要将更改反向移植到稳定分支,我想每个分支的单独更改需要推送进行修订,即使樱桃选择是干净的.

关于您的Gerrit工作流程体验的一般评论也是受欢迎的.

Answer 1

1. Gerrit被一些非常庞大的项目使用,例如Android和相关的bsp,内核等存储库.这些项目每周超过50次外部提交.我认为高通公司将在这段时间内进行数千次提交.

2. Gerrit中有一个设置可以自动合并琐碎的冲突.这可以按存储库设置.如果设置了此选项,则在检查并验证更改并且用户按下"提交"按钮后,将根据您的提交策略(樱桃选择,必要时合并)合并更改.我能找到的最好的文档是--use-content-merge选项下的http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options.

3. 是的,这通常是我们做事的方式.还有其他选择(绕过审查,合并分支机构等),但挑选到需要的分支和审查工作很好.