Jenkins并行PR修改同文件，如何自动解决Git合并冲突？

一、从根源避免冲突：拆分文件架构（推荐） #

你的核心问题是所有PR都修改同一个test.yml，并行操作必然导致冲突。结合微服务场景，最彻底的解决方式是拆分告警规则文件：

• 在alert-repo中创建alerts/目录，每个微服务对应一个独立的告警规则文件，比如alerts/app1.yml、alerts/app2.yml
• 每个PR仅修改对应应用的告警文件，完全避免同一文件的并行修改冲突
• CI阶段通过脚本或Helm特性合并所有文件为最终的test.yml：
  1. 用yq工具合并：

     yq eval-all '.alerts = (reduce .[] as $item ([]; . += $item.alerts)) | unique_by(.name)' alerts/*.yml > test.yml
     

  2. 或直接在Helm Chart中通过Files.Glob动态加载所有告警文件，无需提前合并：

     # elasta-alert的values.yaml
     alerts: []
     {{- range $file := .Files.Glob "alerts/*.yml" }}
       {{- .Files.Get $file | nindent 2 }}
     {{- end }}
     

二、Git自定义合并驱动：自动解决单文件冲突 #

如果无法调整架构，可通过Git自定义合并驱动，针对test.yml的结构化内容自动合并变更，无需人工干预：

步骤1：配置Git属性 #

在仓库根目录创建.gitattributes文件，指定test.yml使用自定义合并规则：

test.yml merge=alert-merge

步骤2：编写合并脚本 #

创建scripts/alert-merge.sh脚本（赋予执行权限chmod +x scripts/alert-merge.sh），用yq处理YAML的结构化合并：

#!/bin/bash
# Git合并驱动脚本：合并本地、远程、祖先版本的alerts数组，按name去重
# $1: 祖先版本文件, $2: 本地版本文件, $3: 远程版本文件, $4: 合并后输出文件
yq eval-all '.alerts = (.[0].alerts + .[1].alerts + .[2].alerts) | unique_by(.name)' "$1" "$2" "$3" > "$4"
exit 0

注：脚本逻辑可根据你的test.yml结构调整，比如合并不同的字段、处理嵌套结构等。

步骤3：注册合并驱动 #

在Git配置中注册这个自定义驱动（可全局配置或仓库级配置）：

# 仓库级配置（仅当前仓库生效）
git config merge.alert-merge.driver './scripts/alert-merge.sh'

# 全局配置（所有仓库生效）
git config --global merge.alert-merge.driver '/path/to/alert-repo/scripts/alert-merge.sh'

步骤4：优化PR流程 #

为了减少冲突概率，在Jenkins Pipeline创建分支前，先拉取最新的master分支：

stage('Create Feature Branch') {
  steps {
    script {
      git url: 'git@your-repo/alert-repo.git', branch: 'master'
      sh 'git pull origin master'
      sh "git checkout -b pr-${BUILD_NUMBER}"
    }
  }
}

三、补充说明 #

• 自定义合并驱动仅适用于结构化的YAML变更（比如新增数组条目、添加键值对），如果PR存在对同一字段的修改（比如修改同一个告警的阈值），还是需要人工介入，但这种场景在你的业务中应该极少。
• 拆分文件的方案不仅解决冲突，还能让告警规则的归属更清晰，便于维护。

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