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

Question

我们正在考虑将 Gerrit 用于大型项目。此时，了解人们如何处理已批准变更的合并冲突将会很有趣。

想象一下，许多不同规模的变更正在同时等待修订，并且正在逐步审查和验证。由于其中一些人可能会修改同一段代码，因此冲突是不可避免的。如果“集成商”在简单的工作流程中手动接受补丁，这不是问题，小冲突可以在途中解决，但使用 Gerrit 情况就不同了。当更改经过审核和批准后，如果发生合并冲突，据我了解，作者需要重新调整基础并再次插入修订，在这种情况下，修订过程将再次开始。在相对活跃的项目中，每周有超过 50 个外部贡献者提交，如果在每次批准和提交后由于合并拒绝而需要多次修改同一补丁，这可能会变成噩梦，这似乎是效率不高。

问题:

1. 对于预计会出现大量合并冲突的大型事件，Gerrit 并不是一种前进的方式，我这样说对吗？

2. 一些合并冲突可能是微不足道的，有没有办法解决它们而不需要麻烦作者重新提交更改？

3. 如果需要将更改向后移植到稳定分支，我猜想每个分支的单独更改都需要推送进行修订，即使 cherry-pick 是干净的。

   <

也欢迎对您的 Gerrit 工作流程体验提出一般性评论。

Answer 1

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

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

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