PR diff与Git Lens提交状态不一致的原因咨询及技术解释

核心原因：Git的重命名检测是基于内容的启发式逻辑，而非操作记录 #

Git本身不追踪文件的重命名操作，它不会记录你是用git mv还是手动改的文件名。所有的“重命名”识别，都是Git在生成diff、blame或日志时，通过对比文件内容的相似度（默认是50%以上匹配）反向推断出来的。这就导致不同工具、不同参数下，对同一份提交的解读可能不一样。

1. PR平台与本地Git的diff算法参数差异 #

PR平台（比如GitHub、GitLab）的diff生成逻辑，可能默认更偏向于保留“原目录变更”的直观呈现：

• 你手动把Hello改成World，再新建Hello放相同文件，PR的diff会优先把原Hello的删除和新Hello的修改关联，显示Hello是变更（红删绿加），而World是完全新增的目录。

而本地Git（包括Git Lens依赖的Git核心逻辑）的默认diff参数，可能更敏感于内容完全匹配的情况：

• 因为World里的文件和原Hello的内容100%一致，Git会把World推断为原Hello的重命名，而新Hello则被识别为全新的新增文件——这就是Git Lens显示Hello是新增、World带原作者信息的原因。

2. Git Lens的显示依赖Git Blame的结果 #

Git Lens的文件作者信息来自git blame命令，而git blame会遵循Git的重命名推断：

• 如果Git把World/xxx识别为原Hello/xxx的重命名，那么blame会沿用原文件的提交作者信息；
• 新Hello/xxx是完全新建的文件，所以blame直接显示当前提交的作者（也就是你）。

3. 为什么用git mv通常不会有这种差异？ #

git mv old new本质上只是帮你执行了rm old + add new的操作，并没有给Git额外的重命名标记，但它会让Git在提交时，更倾向于把这组操作关联成重命名（因为操作是连续的，且文件内容完全一致）。但即使如此，Git的重命名识别依然是内容驱动的，极端情况下还是可能出现解读差异。

验证方法 #

你可以在本地手动执行git diff --find-renames=100% <目标提交>^ <目标提交>，看看Git的diff结果：

• 如果用--find-renames=100%（要求内容完全匹配才识别重命名），应该会和Git Lens的显示一致；
• 如果降低阈值（比如--find-renames=50%），可能会更接近PR的diff结果。

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