只改一个空格，Git 是怎么发现的？

Git 把文件内容保存为数据对象，通常叫 blob，并根据对象内容和类型、长度等头部信息计算对象编号。相同字节内容在同一种对象格式下可复用同一个 blob。它不是只取文件名当编号，也不是把文件最后修改时间当成内容本身。

那文件名去了哪里？目录树对象记录名字、文件模式以及它指向的内容对象或子目录。提交对象再连接一次目录快照和历史信息。把内容与名字分开，就能解释为什么两条不同路径可以引用相同内容，也能解释文件内容未变时，改名仍属于项目状态变化。

日常最重要的三处状态，是正在编辑的工作区、为下一次提交准备的暂存区，以及已经保存的提交。假设原文件写着 blue，你改成 green 后执行 git add，再改成 red。此时暂存区保留的是 green，工作区则是 red，不会因为继续编辑就自动同步暂存区。

所以这个文件可能同时出现在已暂存与未暂存改动里。普通 git diff 主要比较工作区和暂存区；git diff --cached 比较暂存区和已提交状态。两者都没有显示某段变化时，应先检查自己选的比较对象，而不是立刻认定 Git 漏记了编辑过程。

文件很多时，完整读取所有内容会花时间。Git 的索引除了记录内容对象，还会保存文件状态信息，并可利用文件系统提供的时间、大小等信息以及其他机制减少不必要的检查。这些是帮助筛选的线索，不能简单理解为“修改时间变了就一定有内容改动”。

当需要确认内容时，Git 会按相关规则比较它。你把一个已跟踪文件改了又完整改回原样，最终可能不再有内容差异，即使文件曾经被写过。屏幕上的红绿行则是把两份内容作差异展示的结果，不是仓库逐个保存了你打字、删除、撤销的动作录像。

空格、末尾换行和不同换行表示都可能影响字节内容。但 Git 又能按属性和配置把文本换行统一后保存，因此工作区的原始字节与仓库保存的字节未必完全相同。看到整篇都变红时，先检查是否换行格式或编码改变，比重新手工复制所有文字更有效。

理解机制后，可以养成一个简单习惯：提交前分别查看未暂存差异和已暂存差异，确认这次真正准备保存的内容。识别改动也不等于自动备份所有编辑；尚未保存到 Git 对象或提交中的内容不能靠“Git 应该看见过”来保证找回。