Git合并因相似度索引误判：如何修正？

这个问题其实是Git自动重命名检测机制的常见坑——它靠文件内容相似度（默认阈值50%）来判断文件的移动/重命名关系，如果master里的C文件和原A有不少相似内容，或者B文件被改得和原A差异太大，Git就会认错“对应关系”。下面给你几个靠谱的解决办法：

方法1：禁用自动重命名检测，手动处理合并 #

先让Git别自作主张识别重命名，咱们自己来指定正确的文件对应：

• 切换到master分支：

  git checkout master
  

• 执行合并时禁用自动重命名检测：

  git merge --no-renames feature-branch
  

  这时候Git会显示：特性分支修改了A/CMakeLists.txt，但master里这个文件已经被删除（因为移到B了），同时B/CMakeLists.txt是master里的新文件。
• 手动把特性分支中A/CMakeLists.txt的改动合并到B/CMakeLists.txt里，完成后：

  # 移除特性分支里的A文件（因为master已经把它移到B了）
  git rm A/CMakeLists.txt
  # 添加修改后的B文件
  git add B/CMakeLists.txt
  

• 最后提交合并结果：

  git commit
  

方法2：调整重命名检测阈值，引导Git识别正确关系 #

如果Git是因为B和原A的相似度不够才认错，你可以提高重命名检测的相似度阈值，让Git更“严格”地匹配：

git merge -X rename-threshold=80 feature-branch

这里的80是百分比（范围0-100），意思是只有当两个文件内容相似度超过80%时，Git才会认为是重命名。你可以根据实际情况调整这个数值，直到Git正确识别A→B的移动关系。

方法3：先在特性分支上合并文件移动的变更，再合并到master #

这个方法能从根源上避免Git认错，先把master里“移动A到B”的变更同步到特性分支：

• 切换到特性分支：

  git checkout feature-branch
  

• 找到master中“移动A到B并修改”的那个commit（用git log master查看，假设哈希是abc123），把这个commit Cherry-pick到特性分支：

  git cherry-pick abc123
  

  这时候Git应该能正确识别A→B的移动关系，自动把你在特性分支对A的改动合并到B里，遇到冲突手动解决即可。
• 提交Cherry-pick的结果后，切换回master合并特性分支：

  git checkout master
  git merge feature-branch
  

  这时候因为两边的文件结构已经对齐，Git不会再把A的改动错误合并到C了。

额外小技巧：提前验证Git的重命名识别结果 #

合并前你可以先看看Git当前认为的重命名关系，确认是不是把A和C关联了：

git diff --name-status -M master feature-branch

输出里如果看到R100 A/CMakeLists.txt -> C/CMakeLists.txt这类内容，就说明Git确实认错了，这时候再用上面的方法修正就行。

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