git diff 一片空白，不能单独证明“没有待提交的修改”。更常见的问题是：看错了比较对象。
我用 Git 2.43.0 在一个临时仓库里做了对照：修改一个已跟踪文件，再把它暂存，最后新建另一个文件。整个实验没有连接远程仓库，也不是生产故障复盘。
先看三处，不急着撤销修改
普通 Git 仓库可以先分清三个位置：
- HEAD：当前提交。
- 暂存区：准备进入下一次提交的内容。
- 工作区：磁盘上正在编辑的文件。
不带额外比较对象的 git diff，主要比较工作区与暂存区。已经用 git add 放进暂存区的修改，要用 git diff --cached 看它相对 HEAD 的差异。[2]
所以，“空白”的意思只是这一次比较没有差异，不是这三个位置全都一致。
同一处修改，暂存前后输出不同
实验先提交了一份内容为 before 的 note.txt，随后把它改成 after。
还没有暂存时，git diff 能看到这处修改；git diff --cached 没有输出。执行下面这条命令后，情况正好反过来：
git add note.txt
此时普通 git diff 变成空白，但 git diff --cached 仍显示删除 before、增加 after。内容没有消失，只是工作区与暂存区已经相同，暂存区与当前提交仍不同。
接着，我新增了 scratch.txt，没有执行 git add。git status --short 的实际输出是：
M note.txt ?? scratch.txt
第一行表示 note.txt 有已暂存的修改；第二行表示 scratch.txt 尚未被跟踪。默认的 git diff 在这个状态下仍然没有输出。git status 可以同时帮助检查暂存、未暂存和未忽略的未跟踪文件。[3]
我的检查顺序：先状态，再按范围看差异
在普通、已有提交且没有合并冲突的仓库里，我会按这个顺序检查：
git status --short git diff git diff --cached
- 想看还没暂存的修改，用
git diff。 - 想看准备提交的修改，用
git diff --cached。 - 想将已跟踪文件的工作区状态与当前提交比较，可用
git diff HEAD。它不会因此把未跟踪文件的正文也列出来。[2]
新文件先从状态列表里找，读完内容、确认需要纳入版本控制，再决定是否暂存。不要为了让差异出现，就顺手执行一次不加区分的 git add .。
这个顺序不负责解决合并冲突、子模块或忽略规则的全部问题。它只回答一个容易误判的小问题：差异命令没有输出时，先问它在比较谁与谁，再判断代码有没有变化。
本文为 AI 辅助整理的原创工具实验；输出来自隔离样本，不代表线上项目收益。
参考资料
以下为Git官方手册，核验于2026年10月23日。
[2] Git diff 官方手册
[3] Git status 官方手册
