Git合并时相同“双方新增”文件、EoL/权限差异被误判为冲突

三类异常冲突的核心诱因基本都指向三方合并基准异常、配置作用域理解偏差，和Git本身的自动合并逻辑无关，具体对应场景的排查和处理方式如下：

1. 内容/哈希完全一致却触发both added冲突 #

触发原因 #

• 两个分支的提交历史存在断层：之前执行过--allow-unrelated-histories强制合并不相关历史、用filter-branch/filter-repo重写提交时未保留原commit哈希、或者误操作将大量文件删除后重新提交，导致同路径文件在两个分支的提交链中都被标记为「独立新增」，无法溯源到共同祖先中的对应文件。这种场景下哪怕两个分支的文件内容、哈希100%一致，Git也不会做自动合并。
• TortoiseMerge这类GUI合并工具没有内置「同内容both added自动标记解决」的逻辑，只会逐个弹出冲突提示，放大了操作成本。

处理方案 #

冲突触发后不要逐个手动标记，直接在仓库根目录执行命令批量解决所有同内容的both added冲突：

git diff --name-only --diff-filter=U | while read -r file; do
  # :2 代表当前分支版本，:3 代表待合并分支版本，哈希一致则直接标记为已解决
  if [ "$(git hash-object ":2:$file")" = "$(git hash-object ":3:$file")" ]; then
    git add "$file"
  fi
done

如果要从根源避免后续合并复现，找到两个分支上次正确合并的commit，通过git replace设置正确的父节点关联，修复文件的溯源链路即可。

2. 行尾符(EoL)冲突配置不生效 #

触发原因 #

• merge.renormalize、-Xignore-space-at-eol这类参数仅对「文件内容差异仅为行尾符、且三方合并的三个版本blob可正常做转换」的场景生效。如果没有在仓库级配置.gitattributes强制行尾规则，仅靠本地git config设置，只会影响本地检出/提交时的转换逻辑，不会作用于合并阶段的三方blob对比。
• 如果索引中已经缓存了不同行尾格式的文件blob，renormalize逻辑不会主动覆盖缓存内容，导致参数失效。

处理方案 #

1. 在仓库根目录创建.gitattributes文件提交到仓库，强制全仓库文本文件的行尾规则，从根源消除行尾差异：

   # 所有文本文件默认检出/提交时自动转换，统一用LF作为仓库内存储格式
   * text=auto eol=lf
   # Windows批处理文件单独指定CRLF
   *.bat text eol=crlf
   *.cmd text eol=crlf
   # 二进制文件跳过所有转换
   *.jar binary
   *.png binary
   *.exe binary
   

2. 清除本地索引缓存，让行尾规则生效：

   git rm --cached -r .
   git reset --hard
   

3. 后续合并如果仍有残留行尾冲突，直接用更彻底的空白忽略参数执行合并：

   git merge -s recursive -Xignore-all-space
   

   该参数会忽略所有空白类字符差异，不会修改实际代码逻辑。

3. core.fileMode=false 仍触发可执行位权限冲突 #

触发原因 #

core.fileMode=false的作用域仅为本地工作区的权限变更，不会修改已经写入提交历史的文件mode值。如果两个分支的提交记录中，同个文件的blob mode一个是100644（普通文件）、一个是100755（可执行文件），哪怕内容完全一致，Git合并时依然会识别为差异触发冲突。这类问题大多是跨平台提交导致的：Windows环境下的GUI客户端（比如TortoiseGit）可能会在提交时自动给文件加上可执行位，和Linux/macOS环境提交的文件mode不匹配。

处理方案 #

1. 冲突触发后批量解决所有内容一致、仅权限不同的冲突：

   git diff --name-only --diff-filter=U | while read -r file; do
     # 对比两个分支版本的文件内容，无差异则直接标记解决，忽略mode区别
     if git diff ":2:$file" ":3:$file" --quiet; then
       git add "$file"
     fi
   done
   

2. 批量对齐两个分支的文件权限，避免后续合并复现：

   # 拉取远程分支的所有文件权限列表
   git ls-tree -r 待合并的远程分支名 | awk '{print $1, $4}' > /tmp/remote_mode.tmp
   # 批量更新本地索引的文件mode
   cat /tmp/remote_mode.tmp | while read -r mode path; do
     perm=$((8#${mode: -3}))
     git update-index --chmod=$perm "$path"
   done
   rm /tmp/remote_mode.tmp
   

3. 可以配置仓库提交钩子，提交时自动修正非必要文件的可执行位，Windows环境下默认将所有文本文件设为普通644权限即可，仅给需要执行权限的脚本文件单独加可执行位。

兜底排查：如果以上操作完成后仍有超预期的大量冲突，执行git merge-base --all HEAD 待合并分支名查看返回的共同祖先commit，如果返回多个结果，说明两个分支存在多合并基准问题，一般是之前重复cherry-pick大量提交、错误执行subtree合并导致的。这种场景下合并时加-s resolve参数，用resolve策略取单个共同祖先做合并基准，即可过滤掉绝大多数无意义的both added冲突。

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