Git突然丢失已移动文件追踪关系的原因及恢复方法咨询

问题1：追踪关系为什么会突然失效？ #

你点到了关键——这确实和Git的快照核心机制以及它的重命名推断逻辑直接相关：

Git从不会记录“移动/重命名”这个操作本身，它只会在对比两个快照（比如分支分叉点的快照、当前分支的快照）时，通过文件内容相似度来反向推断是否发生了重命名。默认情况下，Git的判定阈值是50%：如果两个文件的内容相似度超过一半，就会被识别为同一个文件的演变。

那为什么之前合并正常，现在突然出问题？大概率是这几个原因：

• 分支B上的文件在移动后，后续的迭代修改（比如你改了类名+持续开发）让它和M分支上原文件的内容相似度降到了50%以下，Git没法再匹配上。
• M分支上的原文件在分叉后也做了大量修改，两边的文件差异越来越大，突破了Git的识别阈值。
• 某次合并时的快照对比逻辑没有覆盖完整的演变链，比如中间有提交跳过了关键的对比步骤，导致Git的追踪链断裂。

简单说就是：Git现在对比M和B的当前快照时，没法把M的旧文件和B的新文件关联成“同一个文件的不同状态”，所以把M的旧文件当成了B分支里缺的新文件，B的文件则被视为完全独立的另一个文件。

问题2：怎么恢复两者的追踪关系？ #

根据你的场景，有几个可行的方案：

1. 合并时强制Git识别重命名 #

如果是在合并M到B的过程中触发的问题，可以调整重命名检测的阈值，让Git更容易识别关联：

git merge --rename-threshold=20 M

这里的20是相似度百分比（默认50），你可以根据文件的实际差异调整数值——差异越大，阈值设得越低，Git越容易把它们判定为同一个文件的重命名。

2. 手动修复已完成合并的错误状态 #

如果合并已经完成，M的旧文件已经被错误添加到B分支里，这么处理：

• 先删除B里被误加的旧文件：

  git rm path/to/old-file-from-M
  

• 然后用git log --follow path/to/new-file-in-B确认它的历史确实源自原文件，接着手动标记这个文件的状态为“保留B版本，丢弃M的旧版本”。之后Git在后续的快照对比中会重新建立追踪关系。
• 也可以用git mv再执行一次移动操作（哪怕文件已经在目标路径），这个操作会给Git明确的信号，让后续的重命名检测更顺畅。

3. 回溯历史修复追踪链（谨慎使用） #

如果问题根源在更早的提交，可以用git rebase修改分支B的历史：

• 回到当初移动文件的那个提交，重新用git mv执行移动操作（即使当时已经移过，再执行一次能让Git的快照对比更清晰），然后调整后续的提交内容，确保每一步的快照对比都能关联上原文件。

注意：这个方法会修改分支历史，如果B已经推送到远程仓库，需要和团队沟通后再操作，避免影响他人。

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