如何恢复丢失的git mv操作？解决分支合并后的PR冲突

这种情况我碰到过好几次，核心原因是Git本地的重命名追踪逻辑和Github PR的冲突检测逻辑不一致导致的——你用git mv重命名文件后，合并主干的修改时，本地Git可能自动识别了重命名关联，认为原文件的修改已经同步到新文件里，所以显示状态干净；但Github的PR是直接对比分支与主干的文件树，发现你的分支里原文件被删除，而主干还在对原文件做修改，因此判定为冲突。

下面是具体的解决步骤：

1. 确保本地代码是最新状态 #

先拉取主干的最新代码，避免本地和远程主干有差异：

git fetch origin trunk
git checkout 你的分支名
git merge origin/trunk

这一步如果本地还是显示无冲突，那就是典型的“幽灵冲突”，需要手动修复。

2. 恢复主干中的原文件并合并内容 #

因为PR提示的冲突是原文件被删除，而主干有修改，所以先把主干里的原文件内容拿过来：

git checkout origin/trunk -- 原文件名

此时你本地会同时存在原文件和重命名后的新文件，接下来手动将原文件中的最新修改合并到新文件中——打开两个文件对比，把主干对原文件的修改同步到新文件里，解决可能的内容冲突。

3. 清理原文件并提交修改 #

合并完成后，删除原文件：

git rm 原文件名

然后提交修改：

git add 新文件名
git commit -m "Resolve PR conflict: sync trunk changes from [原文件名] to [新文件名]"

4. 推送更新到远程分支 #

最后推送到你的远程分支，PR会自动更新并检测冲突是否解决：

git push origin 你的分支名

补充说明 #

Git的重命名检测依赖文件内容的相似度，当你用git mv操作后，Git会记录这个重命名关系，但跨分支合并时，如果主干对原文件的修改较多，或者本地合并时的自动关联没触发，就会出现本地无冲突但PR报冲突的情况。这种冲突不是代码内容的直接冲突，而是文件树结构的逻辑冲突，手动同步内容后就能解决。

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