git diff默认不显示重命名文件差异，需显式启用-M（--find-renames）选项并合理设置相似度阈值（如-M70%），配合--name-status可输出R100等重命名状态；否则仅显示孤立的deleted/new记录。
git diff 默认不显示重命名文件的差异
Git 在默认配置下，对重命名检测是“被动触发”的：只有当一个文件被删除、另一个同内容（或相似）文件被新增时，git diff 才可能将其识别为重命名——但前提是开启重命名检测且满足相似度阈值。否则你只会看到 deleted file 和 new file 两条孤立记录，完全看不出关联。
关键点在于：git diff 不是“自动感知重命名”，而是“在满足条件时推断重命名”。所以必须显式启用相关选项：
-
-M（或--find-renames）：开启重命名检测，使用默认相似度阈值（50%） -
-M70%：把阈值调高到 70%，减少误判（适合代码重构后文件内容变动较大的场景） -
-C（或--find-copies）：额外检测跨文件复制（常和-M一起用）
对比两个 commit 时显示重命名差异的正确命令
假设你想看 abc123 到 def456 之间哪些文件被重命名并修改了内容，直接运行 git diff abc123 def456 是看不到重命名关系的。必须加 -M：
git diff -M abc123 def456
如果发现 Git 把不该算重命名的也标出来了（比如两个无关文件恰好有 55% 内容相似），就收紧阈值：
git diff -M80% abc123 def456
注意：-M 必须放在 git diff 后、commit 范围前，顺序错（如写成 git diff abc123 def456 -M）在旧版 Git 中可能失效。
- Git 2.9+ 支持
-M放在任意位置，但为兼容性建议前置 - 如果只关心重命名本身，不关心内容差异，可加
--name-status：git diff -M --name-status abc123 def456，输出类似R100 old.py new.py -
R100表示 100% 相似（纯重命名），R87表示 87% 相似（重命名 + 小改）
git log -p 看历史提交时如何带出重命名信息
用 git log -p 查看某次提交的 patch，默认也不显示重命名。需要给 log 命令单独传参：
git log -p -M
或者更常用的是结合 --follow 追踪单个文件的重命名链：
git log -p -M --follow -- path/to/old-name.py
这里 --follow 会自动启用重命名检测，并把历史中所有重命名后的路径串起来；但注意它只对单个路径生效，不能用于范围 diff。
-
--follow无法和--all或多个路径混用 - 如果提交里既有重命名又有大量内容改动，
-M阈值设太低会导致 Git 放弃重命名推断（转而当作 delete+add），此时应提高阈值而非关闭 - 某些 GUI 工具（如 VS Code GitLens）底层也依赖
-M参数，若它们不显示重命名，先检查是否启用了该选项
重命名检测失败的常见原因和绕过方法
即使加了 -M，仍可能看不到 R 标记——不是命令写错了，而是 Git 的检测逻辑被卡住了：
- 两版本间文件被删了，但新文件没被 stage 或没 commit：Git 只比较已索引/已提交状态，未暂存的新增文件不会参与重命名匹配
- 重命名后又做了大改（比如重写了整个文件），相似度低于阈值：此时可临时降低阈值测试，如
-M30%，确认是否真为重命名 - 文件权限变更（如
chmod）干扰了内容哈希：Git 默认忽略权限，但若core.filemode=false，可能影响比对逻辑 - 二进制文件（如图片）被重命名：Git 不做内容相似度分析，仅靠文件名启发式匹配，成功率极低；此时只能靠
--name-status结合人工核对
真正难处理的是“重命名 + 大幅重构 + 混合提交”——这种情况下，git diff -M 很可能放弃推断，你得拆成两次提交（先重命名，再改内容）才能让历史清晰可读。
