GitLab CE 10.2.4下Fast-forward合并多MR场景解决方案咨询

我之前维护旧版本GitLab团队时，也碰到过一模一样的问题——多个并行MR往受保护分支推，每次合并一个就得让其他人重基，折腾得不行。结合当时的实践，分享几个可行的方案：

一、优化Fast-forward/半线性合并的多MR工作流 #

如果你们团队坚持要保持线性提交历史，试试这几个方法减少重复操作：

• 拆分小MR，高频合并：要求团队把大功能拆成多个小MR，每个MR只解决一个具体问题（比如修复一个bug、添加一个小功能点）。小MR不仅Review更快、CI执行时间短，还能降低和其他MR的冲突概率，减少合并后的重基工作量。
• 添加MR预检查CI脚本：虽然这个版本不能自动测试MR合并后的结果，但可以在CI中加一个专门的job，在MR创建时自动拉取目标分支与当前分支合并，跑一遍测试并反馈结果。这样开发者能提前发现冲突或测试失败，不用等别人合并后才踩坑。示例脚本如下：

# .gitlab-ci.yml 中新增预检查任务
mr-precheck:
  stage: pre-check
  only:
    - merge_requests
  script:
    # 拉取目标分支最新代码
    git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    git checkout $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    # 合并当前MR分支（不生成合并提交）
    git merge --no-ff $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
    # 执行项目测试命令，替换成你们的实际测试脚本
    ./run-tests.sh

这个job会在MR创建时自动触发，一旦合并失败或测试不通过，开发者就能立刻处理，避免后续被动重基。

• 专人集中合并MR：每天固定一个时间段（比如下午3点），由团队中的一个人集中处理所有打开的MR。操作时先拉取目标分支最新代码，依次合并所有MR并测试，完成后统一通知所有人更新自己的分支，重基到最新的目标分支上。这样能避免合并过程中有人插队，减少冲突次数。

二、无需快进合并也能保证合并前测试的替代方案 #

你的核心需求是代码合并前必须通过CI测试，而非强制快进合并。针对这一点，有更省心的方案：

• 使用「合并提交」模式 + MR管道校验：GitLab CE 10.x已经支持在MR设置中开启「仅当管道成功时允许合并」（在MR的「设置」标签页中找到该选项）。虽然默认的管道是MR分支本身的测试，但我们可以把之前的预检查job设为必须通过的任务，确保MR分支与目标分支合并后能通过测试。这样即使使用非快进的合并提交模式，也能保证代码质量，且多个MR之间不会互相影响——合并一个MR后，其他MR只需重新触发CI（或自动触发），测试通过后即可直接合并，无需重基。
• 搭建定时合并测试分支：创建一个专门的merge-test分支，通过GitLab定时CI任务，每天自动将所有打开的MR分支合并到该分支并跑全量测试。如果某个MR合并后出现问题，立刻通知对应的开发者修复，提前发现跨MR的代码冲突。示例脚本如下：

merge-test-schedule:
  stage: test
  only:
    - schedules # 仅定时触发
  script:
    # 拉取目标分支最新代码
    git checkout develop
    git pull origin develop
    # 创建临时测试分支
    git checkout -b merge-test-temp
    # 通过GitLab API获取所有打开的MR源分支
    MR_BRANCHES=$(curl --header "PRIVATE-TOKEN: $GITLAB_PRIVATE_TOKEN" \
      "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests?state=opened" | jq -r '.[].source_branch')
    # 依次合并所有MR分支
    for branch in $MR_BRANCHES; do
      git merge --no-ff origin/$branch || exit 1
    done
    # 执行全量测试
    ./run-full-tests.sh

注意：这个方案需要配置GitLab私有Token，并在CI runner中安装jq工具解析API返回结果。

我们团队当时最终采用的是「合并提交模式+MR预检查CI+仅当管道成功时允许合并」的方案，既满足了代码质量要求，又摆脱了强制快进带来的繁琐重基操作。如果你们特别在意提交历史的整洁，也可以结合第一部分的优化方法来平衡。

内容的提问来源于stack exchange，提问作者user2641570