合并冲突时让Git识别已移动文件的解决方案

临时解决（无需重写历史） #

针对当前正在处理的合并冲突，可通过以下步骤让Git重新识别文件移动操作，简化冲突解决：

• 先终止当前合并
  如果已经进入冲突状态，先回到合并前的干净状态：

  git merge --abort
  

• 提高重命名检测敏感度
  重新执行合并时，调整重命名检测阈值，让Git更容易识别高改动率的文件移动：

  git merge -X rename-threshold=50% <目标分支名>
  

  rename-threshold取值0-100%，数值越低，Git越容易判定文件为重命名（哪怕文件改动很大），可根据实际情况调整，比如设为30%。
  也可以搭配-M参数强化检测：

  git merge -M -X rename-threshold=50% <目标分支名>
  

• 手动关联文件（自动检测失效时）
  如果上述命令仍不生效，手动告诉Git旧文件和新文件的关联：

  1. 先执行合并，允许冲突产生：

     git merge <目标分支名>
     

  2. 对每个误判的文件，执行：

     git merge-file <新文件路径> <旧文件路径> $(git rev-parse <目标分支名>:<旧文件路径>)
     

     执行后再用git add标记冲突已解决。

长期规范（避免后续同类冲突） #

如果团队允许重写分支历史，可修正自己的提交记录，让Git全程追踪文件移动：

• 定位移动文件的提交
  用git log --oneline找到手动移动文件的提交哈希。

• 交互式重写历史

  git rebase -i <该提交的父提交哈希>
  

  在编辑器里把该提交的pick改成edit，保存退出。

• 改用git mv重新移动文件
  先撤销手动移动的更改：

  git reset HEAD^
  git checkout HEAD^ -- <旧文件路径>
  rm <新文件路径>
  

  再用Git命令移动：

  git mv <旧文件路径> <新文件路径>
  

  复用原提交信息重新提交：

  git add .
  git commit -C <原提交哈希>
  

• 完成rebase并推送

  git rebase --continue
  git push --force-with-lease
  

  注意：强制推送仅适用于未被其他开发者共享的分支，否则会破坏他人的提交历史。

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