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