GitLab CI/CD分支合并频繁冲突，但本地合并无异常问题排查

1. 并发流水线导致分支状态不一致 #

当多个development分支的推送操作同时触发CI流水线时，第一个流水线完成合并并推送demo分支后，后续流水线执行git fetch origin demo development时，拉取的demo分支仍是合并前的旧版本。此时用旧demo分支合并最新development自然会出现冲突——而你本地操作时拉取的是合并后的最新demo，因此不会有冲突。

解决方法：

• 在合并前重新拉取demo分支最新状态，比如在git merge前添加git pull origin demo；
• 给流水线添加互斥锁，确保同一时间只有一个合并任务运行；
• 改用git rebase（注意需处理强制推送的风险）。

2. Git换行符配置差异 #

本地和CI环境的core.autocrlf或core.eol配置不一致，会导致文件换行符被Git识别为不同内容。比如本地开启自动转换（autocrlf=true），CI环境保持原始换行符（autocrlf=false），合并时换行符差异会被判定为冲突，但本地因自动转换无法感知。

排查方法：

• 在CI脚本中添加git config --get core.autocrlf和git config --get core.eol，对比本地配置；
• 在CI脚本中显式统一配置，比如git config --global core.autocrlf false（根据项目需求调整）。

3. 文件系统大小写敏感性差异 #

本地如果是Windows或默认配置的macOS，文件系统大小写不敏感；而CI环境通常是Linux，文件系统大小写敏感。若项目中存在大小写不同的同名文件（比如README.md和readme.md），本地会视为同一文件，但CI环境中是独立文件，合并时会因文件存在性冲突报错，本地操作则不会暴露该问题。

排查方法：

• 在CI脚本中添加ls -la查看冲突文件所在目录的文件列表，检查是否有大小写差异的文件；
• 清理项目中重复的大小写文件，统一命名规范。

4. Runner工作目录未完全清理 #

如果CI Runner配置了保留工作目录（未启用clean: true），每次流水线运行可能残留之前的分支或文件状态。比如本地已存在demo分支，git checkout -b demo origin/demo会失败，但脚本未处理该错误，后续操作可能基于旧demo分支执行，导致合并冲突。

解决方法：

• 在脚本开头添加git clean -fd和git reset --hard，确保工作目录干净；
• 改用git checkout origin/demo -b demo，强制基于远程分支创建本地分支；
• 在Runner配置中启用clean: true，确保每次流水线在干净环境中运行。

5. Git版本的合并算法细微差异 #

虽然Git 2.47.1和2.48.1版本差异不大，但某些边缘场景下，合并算法的细微调整可能导致CI环境判定为冲突，而本地不会。比如复杂文件的合并逻辑在新版本中做了优化。

排查方法：

• 将CI环境的Git版本升级到2.48.1，与本地保持一致；
• 合并时显式指定合并策略，比如git merge --no-edit -s recursive origin/development（默认即为recursive，显式指定可排除其他策略影响）。

6. 子模块引用冲突 #

如果项目包含子模块，CI环境可能未正确拉取子模块最新状态，而本地已更新子模块。合并时子模块的引用哈希不一致会导致冲突，但本地因子模块已同步无法感知。

排查方法：

• 在CI脚本中添加git submodule update --init --recursive，确保子模块同步到最新状态；
• 检查子模块的分支配置，确保CI和本地使用相同的子模块分支。

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