我正在尝试使用 gitlab-ci 为我的团队设置一个 gitlab worflow。我们有一个 Gitlab CE 版本 10.2.4，其中 gitlab CI 配置为在每次推送时运行构建。现在，我们希望将合并请求工作流与受保护的开发分支和发布分支一起使用。我们的要求是，如果不先在 gitlab-ci 上运行，就不能将任何代码合并到这些分支中，以保持这些分支干净。
由于 gitlab 似乎无法自动测试合并请求，我们唯一的选择是使用Merge commit with semi-linear history或Fast-forward merge.(参见 GitLab 上的开放问题)
问题是，由于这些合并选项需要快进，如果为同一目标分支创建了多个合并请求，则接受一个合并请求会更改目标分支。然后，这可以防止其他合并请求被合并，因为它们不再快进。这意味着每次我们接受合并请求时，我们都必须将所有其他合并请求与目标分支重新定基/合并，这非常乏味。
任何人都可以在 gitlab 上使用Fast-forward merge选项解释他们如何处理这种多重合并请求场景吗？还是有没有其他方法可以确保代码在合并之前经过测试，而无需快进？
在项目设置中，转到"常规"->"合并请求"并选中"仅在管道成功时允许合并请求"。
您正在寻找的功能是合并列车。但是，这仅适用于"高级"。
我们将常规合并请求与在分支上运行的常规管道一起使用。此管道传递是合并 MR 的条件。
我同意两个MR可能会包含更改，每个更改本身都可以，但一起会破坏某些东西。但是，根据我的经验，我认为我没有看到这样的事情。即使它很少发生，我仍然更喜欢它而不是"用半线性历史记录合并提交"或"快进合并"的烦恼。