我们正在考虑将Gerrit用于大型项目。在这一点上，了解人们如何处理已批准变更的合并冲突将会很有趣。
想象一下，不同大小的许多变化同时待修订，并且正在逐步审核和验证。由于其中一些可能正在修改同一段代码，因此冲突是不可避免的。如果“集成商”在简单的工作流程中手动接受补丁，则可以在途中解决小的冲突，但Gerrit的情况有所不同，这不是问题。当审查和批准变更时，如果合并冲突，我理解，它将需要由作者重新定位并再次推送进行修订，在这种情况下，修订过程将再次开始。在相对活跃的项目中，每周有超过50个外部贡献者提交，如果由于每次批准和提交后合并拒绝可能需要多次修改相同的补丁，这可能会变成噩梦，这似乎是没有效率。
问题：
我是否认为Gerrit不是一个预期会出现大量合并冲突的大型活动的前进方式？
有些合并冲突可能很简单，有没有办法解决它们而不需要打扰作者重新发布变更？
如果需要将更改反向移植到稳定分支，我想每个分支的单独更改需要推送进行修订，即使樱桃选择是干净的。
欢迎您对Gerrit工作流程体验的一般评论。
答案 0 :(得分：7)
Gerrit被一些非常庞大的项目使用，例如Android和相关的bsp，内核等存储库。这些项目每周超过50次外部提交。我认为高通公司将在这段时间内进行数千次提交。
Gerrit中有一个设置可以自动合并琐碎的冲突。这可以按存储库设置。如果设置了此选项，则在检查并验证更改并且用户按下“提交”按钮后，将根据您的提交策略（樱桃选择，必要时合并）合并更改。我能找到的最好的文档是{ - 3}} --use-content-merge选项。
是的，这通常是我们做事的方式。还有其他选择（绕过审查，合并分支机构等），但是挑选到需要的分支机构和审核工作很有效。
答案 1 :(得分：4)
我们希望保持历史清洁和易懂，因此也是合理的线性。因此我们将Gerrit配置为仅使用快进合并。唯一可见的合并是发布和支持分支（我们使用git-flow），这使事情更容易理解。
但是，我们安装了trivial-rebase插件，以便先前的审核状态自动应用于重新定位的更改。无论是在Gerrit中使用重定位（使用Rebase按钮）还是由开发人员在本地重新定位并重新推动更改，都会发生这种情况。
根据我们的经验，由于涉及的源文件数量更多，合并冲突在大型项目中实际上并不常见。我们在repo中有大约16,000个文件，有30个全职或兼职开发人员，因此编辑同一个文件的可能性非常低。
在任何情况下，如果两个开发人员正在对同一个文件的同一部分进行更改，那么他们真的应该互相交谈。如果项目体系结构需要频繁更改同一文件（例如某种注册表），则需要重新设计体系结构，使用依赖注入等方法，或者从片段中自动生成该源文件作为构建的一部分。 / p>
答案 2 :(得分：2)
当我们在我们公司遇到合并问题时，开发人员会贬低并推动Gerrit。如果合并很少，他（根据惯例）允许LGTM使用rebase并提交。
我们仍然在争论是否/何时开发人员在更新补丁集时应该重新定位。当父级更改时，在比较补丁集时，UI会变得混乱。
答案 3 :(得分：0)
在使用mercurial几年后，我使用它已经将功能分支合并到默认模式并且我讨厌gerrit。我发现自己有更多的开销来解决通过mercurial或git在非gerrit模式下合并自动解决的琐碎冲突。然后每个人都使用android使用gerrit ergo gerrit是好的，应该适合所有人。