GitLab合并dev到prod时CI配置被合并是否正常？如何规避？

1. 合并请求的行为是否符合预期？你的理解正确吗？ #

答案是肯定的，这种行为完全符合GitLab合并请求的设计逻辑，你的理解也没问题：

• cherry-pick是针对单个或指定提交的操作，你可以精准选择要合并的业务代码提交，跳过.gitlab-ci.yml的修改提交，所以prod分支的CI配置不会被影响；
• 合并请求（MR）的核心是将**源分支的所有变更（包括所有提交里的修改）**合并到目标分支，只要dev分支里有.gitlab-ci.yml的修改记录，合并时就会同步到prod分支，导致prod继承dev的CI配置。

2. 如何避免dev的CI配置变更被合并到prod？ #

这里有几种实用的方案，你可以根据团队情况选择：

方案1：拆分CI配置文件 #

把不同环境的CI配置拆分开，主文件根据分支加载对应配置：

# .gitlab-ci.yml（主配置文件，所有分支共用）
include:
  - local: ".gitlab-ci-dev.yml"
    only: [dev]
  - local: ".gitlab-ci-prod.yml"
    only: [prod]

之后dev分支只修改.gitlab-ci-dev.yml，prod分支只维护.gitlab-ci-prod.yml。即使dev的CI配置文件被合并到prod，也不会被prod的流水线加载，从根源上避免冲突。

方案2：用分支保护+文件审批规则 #

在GitLab的项目设置里：

• 给prod分支开启分支保护，禁止直接推送，必须通过MR合并；
• 设置文件级别的保护规则，要求.gitlab-ci.yml的修改必须经过特定角色（比如运维、团队负责人）的审批才能合并到prod。

方案3：MR流水线自动检查CI配置变更 #

在CI流水线中添加MR阶段的检查脚本，自动拦截包含.gitlab-ci.yml修改的dev→prod MR：

# 示例脚本，放在MR触发的流水线任务中
if [[ "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME" == "dev" && "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" == "prod" ]]; then
  # 检查MR是否包含.gitlab-ci.yml的修改
  git diff --name-only $CI_MERGE_REQUEST_TARGET_BRANCH_NAME...$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME | grep -q ".gitlab-ci.yml"
  if [ $? -eq 0 ]; then
    echo "警告：dev→prod的MR中包含.gitlab-ci.yml的修改，请使用cherry-pick单独合并业务代码！"
    exit 1 # 让流水线失败，阻止合并
  fi
fi

方案4：规范合并流程，用cherry-pick替代MR合并业务代码 #

要求团队在合并dev到prod时，不用MR全量合并，而是用cherry-pick选择需要上线的业务代码提交，跳过所有CI配置相关的提交，确保prod分支的CI配置不受dev影响。

内容的提问来源于stack exchange，提问作者Zakaria Ait Yakoub