什么是合并队列？

Question

合并队列越来越流行（Trunk Merge、GH Merge Queue、GitLab Merge Trains），但与立即合并拉取请求相比，它们的目的是什么？

Answer 1

合并队列多年来一直在大型科技公司中流行 - 优步、Airbnb、Twitter、Robinhood、Shopify 等等都建立了自己的内部版本。最近，已经开始出现一些商业托管和开源替代方案。具有更多活动的存储库需要更糟糕的合并队列，这就是为什么大公司不遗余力地创建自己的。

本质上，合并队列增加了一轮额外的测试，必须在拉取请求被自动合并之前通过测试。这种额外的测试可以防止多个 PR 合并，这些 PR 相互冲突，否则可能导致构建损坏或测试失败。使用单个 repo 的人越多，它就越重要，否则你的主分支在大多数情况下都会以某种方式“损坏”。

合并队列提供：

• 防止出现“损坏的 master”（主分支上的构建、测试或功能被损坏 - 更多内容见下文）
• 合并拉取请求的更好工作流程
• 更好的提交消息

它们可以防止“逻辑合并冲突”：

repo 越活跃，合并两个独立工作但共同导致构建、测试或功能失败/中断的拉取请求就越常见。这种现象被称为“逻辑合并冲突”——这里没有 git 合并冲突，而是来自多个 PR 冲突的代码的 逻辑。在中型到大型的monorepos中，这种情况经常发生，以至于主分支实际上从未处于工作状态。

他们在 PR 可以合并之前添加了一轮额外的测试：

合并队列以不同的方式实现，但它们总是提供另一轮拉取请求测试，以确保它们在自动合并拉取之前没有“逻辑合并冲突”（上述情况导致损坏）要求。额外的测试测试多个 PR 的组合。测试哪些组合的详细信息是什么可以使合并队列在规模上发挥作用。

它们的工作原理：

假设 3 个 PR 已准备好并希望在同一时间合并：

• 不是每个作者直接合并，而是每个作者都通过合并队列提交 PR 以进行合并。
• 合并队列为每个 PR 创建新的测试分支。
• PR 1 的测试分支将与最新的 main 分支与 PR 1 合并在一起，并启动 CI 作业以测试其是否有效。
• PR 2 会做同样的事情，但会与 PR 1 的测试分支合并，而不是直接与 main 合并。
• 并且 PR 3 将与 PR 2 的测试分支合并在一起。
• 所有 3 个 PR 可以同时测试，如果所有 3 个都通过，则它们都合并到 main。如果 PR 1 失败，将被踢出让作者修复，PR 2 和 PR 3 将开始基于 PR 1 重新测试 not。
• 此过程一直重复，直到所有 PR 都被退回给其作者进行修复或已合并到您的主分支中。

不同的合并队列采用不同的策略来尝试优化在合并流程中添加另一个测试步骤的延迟和吞吐量，但这就是Trunk Merge 的工作原理。

更好的工作流程：

其中一些系统（Trunk Merge，但不是 GitHub Merge Queue）也实现了比传统合并更好的工作流程，因为一旦您认为您的 PR 准备好合并，您就提交它以进行合并（无论审阅者是否已签署或 CI 作业已通过），它会等到“分支保护”设置通过（通常是 CI 作业已通过且审核者已批准），然后再进入合并队列。

更好的提交信息：

最后，这些系统通常允许将您的 PR 标题和描述转换为最终合并的提交标题和描述，这是一个不错的选择，可以真正改善 git 历史记录。