GitHub Merge Queue、Trunk、Mergify 与 Aviator 对比

速览

四款产品，按它们在「已批准」与「进 main」之间塞进多少机器来排序。第一款免费、开箱即有；另外三款之所以存在，是因为第一款在某个特定的地方停了下来。

继续之前先说一句来源：这个品类的公开对比材料，很多是厂商写彼此的，而且两个方向上都带立场。本文中作为事实陈述的内容，均来自各家产品自己文档中对自身行为的描述；凡是关于竞争对手的说法，我们都略去了。

决定这份候选名单的那笔算术

合并队列做的是串行化：取下一批 PR，把它们放在当前尖端加上排在前面的一切之上测试，通过的就合入。每合入一次变更一趟 CI，这是基线成本；而打包是对这份成本的通用回答。

若每个 PR 在队列里独立地以概率 p 失败，那么 b 个一组通过的概率是 (1−p)^b。不做二分定位时，一个失败就毁掉整组：

右下角那一格就是全部论证。在智能体的失败率上，十个一组每合入一个 PR 要花将近一整趟 CI——你买了打包这套机器、多了一种队列重置的失败模式，然后回到了不打包时的基线。

而 p 不是继承来的。智能体写的变更在队列里失败得更频繁，原因是结构性的：智能体是对着它检出的那个基线提交做核验的，而不是对着它排到队首时真实存在的尖端；它改的文件里有些它没有本地上下文；而它开 PR 的速度快过这棵树平静下来的速度，于是跨智能体的冲突成了常态。数量与 p 一起涨——所以那个对数量的直觉反应「把批次做更大」，是反的。

拯救高 p 下打包的，正是二分定位。把失败的一组劈开、测两半、递归下去：在 b 个里定位出一个罪魁大约多花 2·log₂(b) 趟，而不是全部重跑，而无辜的那些 PR 不必回到队尾。再叠上结果缓存，那些已经作为更大一组的一部分通过过的半区根本无需重跑。

GitHub 合并队列——在一个可计算的门槛之下，它就是正确答案

它做什么

它组成 merge group：你的 PR 与目标分支尖端、以及队列里排在它前面的一切编在一起，必需状态检查对着这一组跑。一个构建并发设置限制同时分发多少个 merge_group webhook，范围 1 到 100，你就是用它来节流并发 CI 的。另有一个设置决定：必需检查失败的 PR 能否被编在一个通过的 PR 后面，还是一组里每个 PR 都必须是绿的。

它在哪里停下

失败时——对着 merge group 的某项必需检查变红、与基线冲突、超过配置的等待时限、或是它无法自动解决的分支保护失败——这个 PR 会被移出队列。它不会对失败的一组做二分定位，也不会从构建图推导出彼此独立的道。一个受保护分支，一条线。

什么时候这就够了

当 p 低而 CI 快时，其余几家卖的那些机器无事可做。请计算你自己的门槛，而不是靠猜：如果在你实测的 p 与你能接受的批次大小下，每合入一个 PR 的期望 CI 趟数已经低于约 0.5，而且你的排队等待由 CI 时长、而非队列深度主导，那么原生队列就不是你的约束，换掉它买到的只是一张账单。对一个流水线十五分钟的单仓库来说，这是常见情形，即便智能体的量已经可观。

Trunk Merge Queue——把二分定位当作主打

失败隔离

Trunk 把兼容的 PR 打成一组，当一组失败时，把它挪进一条单独的队列做二分定位：这一组会以不同方式被劈开、隔离重测，直到罪魁被找出来，而此前通过的结果会被复用，于是这轮隔离不必重跑已经绿过的部分。组里健康的那些 PR 继续往前走。

分道

Trunk 通过与 Bazel、Nx 的构建系统集成，从一次变更实际影响到的目标动态推断出并行的道。没有重叠的变更并发测试、独立合入；有重叠的则编在一起测。前提是有一套能回答「这个 diff 影响到什么」的构建系统——没有的话，分道推导就退化成一张手工维护的路径映射表。

适合谁

一个 monorepo，其中相当大比例的 PR 触及互不相干的区域，而且 p 高到「整组丢弃」成了主要成本。这正是智能体密集的仓库会收敛到的形状。

Mergify——旋钮本身就是产品

打包与推测

Mergify 把批次大小直接暴露出来：1 到 128 的固定整数，或者一个 {min, max} 对象做动态打包——并行检查槽位充裕时用 min，要清积压时向 max 增长。并行（推测式）检查的做法，是创建把排队中的改动与基线分支合起来的临时草稿 PR，并对每一个并发跑 CI，而 max_parallel_checks 限制你要求 CI 吸收多少并发。

排序与作用域

每一组都以「下一个该合入的 PR」作种子——优先级最高的，同优先级里最老的——而打包候选按共享 scope 排序，于是触及同一批声明区域的变更会被编在一起。优先级规则支持为更高优先级的变更中断正在跑的检查。队列冻结则通过 Pause API 处理，并带一个控制「暂停期间检查是否继续跑」的标志。

适合谁

那些想自己调、而不是接受一套既定策略的团队，以及那些想把队列与合并治理规则放进同一个配置文件的团队。动态的 {min, max} 批次大小正是上面那笔算术所说的那个设置——但请注意它是按积压深度调的，不是按 p，所以上限要由你根据实测失败率自己定。

Aviator——针对 flaky 与 monorepo 规模

受影响目标

Aviator 围绕「一次变更触及了什么」来搭：由受影响目标推导出动态队列，于是互不重叠的 PR 各自独立跑，而有重叠的会像并行模式那样被乐观地叠在一起测。

乐观校验

这是它最具辨识度的一块。并行模式下当一组里的测试失败时，Aviator 不会立刻重置队列，而是先等着看后面的批次会不会通过——use_optimistic_validation，配合 optimistic_validation_failure_depth 控制它往后看多远。效果是不让一个 flaky 的必需检查反复丢掉健康的工作。

部署

通过状态检查与 CI 无关地对接，并对 GitHub Actions、Buildkite、CircleCI、Jenkins、GitLab CI 与 Argo 提供一等集成，另有自托管选项——这一组里唯一的一家；如果你的代码权威副本不能跟第三方 SaaS 通信，这就是决定性因素。

随之而来的那条告诫

容忍 flaky 与容忍真实失败，是同一种行为的两个侧面。乐观校验在面对一个确实 flaky 的检查时买到了吞吐；而配置得激进时，它会推迟你发现一个确实坏掉的检查。请把它当成挂在一张有主的、可追踪的隔离清单上的权宜之计，而不是修好那个检查的替代品。

何时选哪个

无论你选哪个，杠杆最高的那处改动都不在产品里。它是在入队时对着队首重新核验每一个 PR，好让一个「对着陈旧状态测过的正确补丁」在分支上便宜地失败，而不是在串行队列里昂贵地失败。这是一处流水线改动，它通常带来 p 的单项最大降幅，并且让这份清单上的每一款产品都更便宜。

延伸阅读

本站：

• 为智能体写的变更建合并队列 —— 建造顺序、入队时的变基，以及该跟的四个指标。
• CI 修复智能体 —— 一次队列弹出该被路由到哪里。
• 补丁生成与测试驱动循环 —— 从源头上把 p 压下去。
• 后台编码智能体 —— 这些数量是从哪儿来的。

产品文档：

• GitHub — Managing a merge queue
• Trunk — Batching and bisection
• Mergify — Merge queue batches 与 parallel checks
• Aviator — Affected targets 与 managing flaky tests