合并列车是什么
合并列车（Merge Train）是 GitLab 为合并请求（MR）提供的串行验证机制：多个 MR 按队列依次排队，每个 MR 在「包含前序合并结果的最新快照」上运行合并后管道，验证通过才真正合入主干。它解决的是语义冲突——两个 MR 在各自分支上各自全绿，合到一起后却可能编译失败或测试互相干扰。列车保证任何时刻主干都处在「已通过合并后验证」的状态，适合要求主干随时可发布的团队。队列中的 MR 验证失败或被更新时会移出队列，后续 MR 基于新的快照重新验证。
基本信息
| 适用平台 | GitLab Premium 及以上（SaaS 与自建） |
|---|---|
| 前置条件 | 合并请求管道 + 快速管道，合并方法为 merge commit |
| 核心语义 | 每个 MR 在包含前序合并结果的快照上验证 |
| 失败处理 | 当前 MR 移出队列，后续 MR 基于新快照重新验证 |
| 容量控制 | 并行列车数按 Runner 容量配置 |
典型使用场景
- 主干必须随时可发布：任何时刻从主干切出的版本都经过合并后验证，发版不必等窗口。
- 高频合并的团队：摆脱「两个 MR 各自绿、合并后红」的手工重试，把组合验证交给队列。
- 单仓多服务的流水线：合并后管道作为统一准入，减少主干被短时间打红的次数。
- 配合「Pipelines must succeed」：把列车作为唯一合入通道，禁止绕过队列直接合。
- 发布前集中修复阶段：队列自然串行化变更，定位「谁把主干弄红了」更容易。
GitLab 开启要点
GitLab 开启要点
项目 Settings → Merge requests：
- 启用 Merge trains
- Merge method 选择 merge commit
- 配置合并请求管道（为每个 MR 运行）
- 勾选 Pipelines must succeed，防止绕过队列直接合并
# 开启后：MR 页面出现 Start merge train 按钮，队列状态可见概念对比
| 机制 | 验证对象 | 典型平台 |
|---|---|---|
| 合并列车 | 包含前序合并结果的快照 | GitLab |
| 合并队列 | 队列合成的临时分支 | GitHub |
| 直接合并 | 仅 MR 自身分支的流水线 | 任意平台 |
队列验证的代价：每个 MR 都要跑一次合并后管道，Runner 消耗按队列长度放大；并行列车数超出容量后等待反而变长。
快速管道用于在进入列车前预跑合并结果，减少「进队才发现失败」的重排；支持矩阵随版本演进，升级前核对官方文档。