Merge Queue 工作流

当一个团队有很多 PR 同时等待进入受保护分支时，真正的瓶颈往往已经不是 review，而是“谁先合、基底是否还新鲜、CI 是否还可信”。
Merge queue 的价值，不是让 PR 排队这么简单，而是把“按什么顺序整合、如何在最新基底上重验”交给平台统一执行。

进入队列前

approved PRprotected branch rulesrequired checks

→enqueue → revalidate → merge

主线得到

顺序可预测基底更新一致减少抢合并窗口

Queue 协调的是整合顺序，不是替代 review 和测试。

这个工作流适合什么团队

它最适合这些情况已经开始频繁出现的团队：

• 同时有很多 PR 等待进入同一条主线
• 分支保护严格，必须带着完整检查才能合并
• PR 经常因为“base changed”重新排队
• 大家花很多时间在等主线空档，而不是在做 review

如果团队规模很小、PR 数量很少，merge queue 可能只是额外流程；但一旦主线并发变高，它会迅速变成“减少摩擦”的工具。

它真正解决的核心问题

1. 通过了不代表还能安全合

一个 PR 在 15 分钟前 CI 通过，不代表现在仍然基于最新主线。
如果几个人都在等合并窗口，这个问题会反复出现。

2. 人工抢合并窗口不可持续

“谁先点 merge”看起来很轻，但当主线繁忙时，会演变成：

• 每个人都在抢最新基底
• 每个人都在反复重跑 CI
• 每个人都觉得自己是被别人插队的那一个

3. 主线稳定性需要统一入口

merge queue 的重点，是让受保护分支只有一种受控进入方式。
这样主线整合就不再依赖个人操作时机。

一个更稳的使用前提

不是所有团队都应该一上来就开 queue。
更稳的前提通常是：

• PR 流程已经成熟
• 必要检查已经稳定
• 分支保护规则已经明确
• 团队愿意把“谁先合”交给流程，而不是人工协调

如果这些前提还没成立，queue 只会把已有混乱包进一个新界面里。

!Merge queue 不能替代 review 质量

它只能协调“进入主线的方式”，不能替代“这次改动到底值不值得进主线”。如果 review、测试和分支保护本来就不稳定，queue 只会把问题排队放大。

团队实际使用时要约定什么

至少要约定这几件事：

1. 哪些检查是 required checks
2. PR 进入 queue 前必须满足什么 review 条件
3. 队列失败后由谁处理、怎么重新入队
4. 紧急修复是否允许走特殊通道
5. 主线是否禁止人工直合

没有这些规则时，merge queue 很容易被当成“另一个 merge 按钮”，结果只是把原来的不确定性换个地方出现。

一条更实用的队列使用节奏

1. PR 在入队前先完成基本同步和自检
2. review 通过后再入队，而不是一边 review 一边排队
3. 队列失败先定位失败类别
4. 修复后重新入队，而不是手动绕开保护规则

这样做的目的，是让 queue 承担“整合协调”，而不是变成“临时救火池”。

常见误区

以为 queue 能代替 pre-review sync

不能。
入队前分支越乱、差异越不清楚，后面失败时越难判断是队列问题还是分支问题。

以为 queue 适合所有团队

小团队、低并发场景下，它未必带来明显收益。

以为 queue 出错时就应该手动强行合并

这通常会把“统一入口”重新打破。除非有明确的紧急绕行规则，否则更稳的做法是修复失败原因再入队。

→团队在启用 merge queue 前先问 4 个问题

1. 主线并发是否已经高到值得队列化？
2. CI 和 required checks 是否足够稳定？
3. 分支保护规则是否已经清晰？
4. 团队是否接受“合并顺序交给系统，而不是交给手速”？

接下来建议继续看什么

1. PR merge strategy and platform settings
2. sync before review
3. shared branch sync boundaries