Gerrit 修订工作流程 : merge conflicts and re-approval

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

想象一下，许多不同大小的更改正在同时进行修订，并且正在逐步进行审查和验证。由于其中一些可能正在修改同一段代码，因此冲突是不可避免的。如果“集成商”在简单的工作流程中手动接受补丁程序就没问题，可以解决一些小的冲突，但是对于Gerrit而言，情况有所不同。据我所知，在变更已被审核并获得批准后，如果发生合并冲突，则需要由作者重新设置其基础并再次推送以进行修订，在这种情况下，修订过程将再次开始。在相对活跃的项目中，每周要提交50多个外部贡献者，如果由于每次批准并提交后合并拒绝而可能需要多次对同一补丁进行修改，这可能会变成噩梦。没有效率。

问题:

我是否正确说Gerrit对于预期大量合并冲突的大型事件对象不是前进的方向？

某些合并冲突可能是微不足道的，有没有一种方法可以解决它们而无需打扰作者重新提交更改？

如果需要将更改反向移植到稳定的分支，我猜每个分支的单独更改都需要推送以进行修订，即使Cherry-pick是干净的也是如此。

也欢迎就您的Gerrit工作流程体验发表一般评论。

最佳答案

Gerrit 被一些非常庞大的项目使用，例如 Android 和相关的 bsp、内核等存储库。这些项目每周获得 50 多个外部提交。我认为高通将在大约这段时间内进行数千次提交。

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

是的，这就是我们做事的典型方式。还有其他选项(绕过审查、合并分支等)，但挑选所需的分支并审查效果很好。

关于Gerrit 修订工作流程 : merge conflicts and re-approval，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10015388/