合并队列是什么
高流转仓库用合并队列按顺序验证待合入的评审请求：队列为每个请求构造临时分支并重跑必需检查，成功后按序合入。它解决的是「各自测试都通过、合并到主干后却失败」这类问题。
基本信息
| 启用位置 | 分支保护规则中要求使用合并队列 |
|---|---|
| 行为 | 进入队列后按序构建，可配置批量大小与超时 |
| 进入方式 | 满足入口条件的评审请求点击合并或自动加入 |
| 失败处理 | 该请求被移出队列，后续请求继续验证 |
| 叠加配置 | 可与压缩合并、必需状态检查等规则一起使用 |
典型使用场景
- 主干合入频繁、并发评审请求较多的仓库
- 流水线较慢但主干稳定性要求高
- 需要减少「合并后主干变红」造成的返工
- 发布窗口前批量合入并保持顺序可控
- 希望合入顺序可预期、出问题可定位
常用示例
常用示例
gh pr merge 128 --squash --auto # 加入队列并自动合并
gh pr checks 128 # 查看检查状态
gh pr view 128 --json mergeStateStatus,isInMergeQueue # 查看队列状态
gh pr view 128 --json autoMergeRequest # 确认自动合并已登记状态与含义
| 状态 | 含义 |
|---|---|
| 排队中 | 等待前面的请求完成验证 |
| 正在验证 | 已在临时分支上重建并运行检查 |
| 验证失败被移出 | 需要修复后重新加入队列 |
| 已合并 | 按序合入主干 |
队列要求请求先满足入口条件，配置过严会让请求卡在入口之外等待，表现为「点了合并却一直不动」。
队列期间推送新提交会触发重新验证，评审请求回到队列末尾，合入时间相应顺延。
批量大小决定一次验证覆盖几个请求：批量大会提高吞吐，但其中一个出问题时影响面也随之扩大。
队列里的验证使用的是为本次合并构造的临时分支，因此其他请求的改动不会混进结果，验证结论可以直接当作合入后的主干状态。