我正在尝试使用 gitlab-ci 为我的团队设置一个 gitlab worflow。我们有一个带有 gitlab CI 的 Gitlab CE 版本 10.2.4，配置为在每次推送时运行构建。现在我们想将合并请求工作流与受保护的开发和发布分支一起使用。我们的要求是，如果不先在 gitlab-ci 上运行，就不能将任何代码合并到这些分支中，以保持这些分支的清洁。
由于 gitlab 似乎没有自动测试合并请求的可能性，我们唯一的选择是使用Merge commit with semi-linear historyor 或Fast-forward merge. （参见gitlab 上的公开问题）
问题是由于这些合并选项需要快进，如果为同一个目标分支创建多个合并请求，则接受一个合并请求会更改目标分支。这会阻止其他合并请求被合并，因为它们不再是快进的。这意味着每次我们接受合并请求时，我们都必须将所有其他合并请求与目标分支重新绑定/合并，这非常乏味。
任何人都可以在 gitlab 上使用Fast-forward merge选项来解释他们如何处理这种多重合并请求场景吗？还是有其他方法可以确保在合并之前测试代码而不需要快进？