GitLab 中的 Merge Train 和 Merge Result 有什么区别

您可以查看Orit Golowinski的文章“合并列车如何让您的 master 保持绿色”

合并列车引入了一种对目标分支中的变更流进行排序的方法（通常master）。
当您的团队在目标分支中进行大量更改时，这可能会导致这样一种情况：在验证一个更改的合并代码期间，另一个更改已合并到主版本，从而使先前的合并结果无效。

（注：Merge Train最初是在gitlab-org/gitlab-fossissue 4176中提出的，后来移至gitlab-org/gitlabissue 3709）

通过使用合并列车，每个合并请求都会作为该列车中的最后一项加入，并且每个合并请求都会按顺序处理。
然而，每个项目不是排队等待，而是获取前一个（待处理）merge ref（合并的合并结果）的完成状态，添加自己的更改，并在一切正常的假设下立即并行启动管道通过。

如果合并队列中的所有管道都成功完成，则不会在排队或重试上浪费管道时间。
因故障而失效的管道会立即取消，导致故障的 MR 被移除，并且队列中的其余 MR 会重新排队，无需人工干预。

合并列车的示例：

MR1 和 MR2 加入合并列车。

当 MR3 尝试加入时，合并失败，并从合并列车中删除。

MR4 在 MR3 失败时重新启动，并尝试在没有 MR3 内容的情况下运行。

MR3 在失败状态下将保持打开状态，以便作者可以在尝试再次合并之前重新设置并修复故障。

这与合并结果的管道不同（仅在 GitLab Premium 11.10 中，2019 年 4 月，第7380 期）

当您提交合并请求时，您正在请求将源分支中的更改合并到目标分支中。默认情况下，CI 管道针对源分支运行作业。

通过用于合并结果的管道，管道运行时就好像源分支中的更改已合并到目标分支中一样。
为管道显示的提交不存在于源或目标分支上，但代表组合的目标和源分支。

这些管道解决的问题是：

团队需要保持master“绿色”。

当有人合并一个破坏 master 的 MR 时，这是一个巨大的痛苦，因为他们不知道存在一些冲突，并且他们的 MR 管道是绿色的。
拥有自己的测试管道是件好事master，因此不会意外部署损坏的代码库，但master留下损坏的代码库并不好，并且任何基于 master 的 MR 现在也会失败。

如果我们有办法在合并之前构建合并的组合结果，那么对结果更有信心将大有帮助。