Git Internals
重命名检测与差异算法
理解 Git 的 rename 检测与 diff 算法有助于解释“为何这个改动显示为删除+新增或重命名”，并优化评审可读性。
- 想建立稳定 Git 心智模型的学习者
- 经常遇到历史、引用、恢复问题的开发者
- 会看基础命令输出
- 知道提交、分支、HEAD 这些名词
- 只背底层术语却不连接到实际命令
- 把对象、引用、工作区混成一层理解
引用与延伸阅读
- Git diff [官方]
- git-scm.com — Git log [官方]
- Git config [官方]
学完这篇你会掌握什么
- 理解 重命名检测与差异算法 的核心作用和适用场景
- 掌握 重命名检测与差异算法 的基本用法和常用参数
- 理解 Git 的 rename 检测与 diff 算法有助于解释“为何这个改动显示为删除+新增或重命名”，并优化评审可读性。
- 理解 重命名是如何推断的 相关的概念
- 掌握 为什么有时看起来像删了再新建 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
Git 并不在对象层“记录文件被重命名”，重命名通常是 diff 阶段推断出来的。
先想一个问题
你每天都在用 Git 命令，但偶尔会遇到一些 '奇怪' 的行为——比如明明没改文件却被提示有改动，或者 rebase 时突然多了预期之外的冲突。你想理解 Git 底层是怎么工作的。
重命名是如何推断的
Git 会基于内容相似度把“删除 + 新增”匹配为 rename。
旧文件路径新文件路径内容相似度
重命名检测行级 diff算法选择
重命名检测不是存储层的真实记录，而是 diff 时的推断。
为什么有时看起来像删了再新建
- 相似度阈值没达到
- 改动量太大
- 参数配置不同（例如是否启用重命名检测）
diff 算法影响什么
不同算法会影响 hunk 切分和可读性，进而影响 review 成本。
实战建议
在大规模重构中，先做“纯重命名提交”再做逻辑改动，通常能显著提升差异可读性。
diff 是展示与比较策略，不是对象数据库里的原生“事件日志”。
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：