Git怎么对比工作区和暂存区_Git diff查看未暂存修改方法【基础】

Git diff 对比工作区和暂存区：核心逻辑与实战避坑指南

git diff 不加参数时对比工作区和暂存区，即显示已修改但未 git add 的内容；不显示已暂存的变更、未跟踪的新文件及已删除未 git rm 的文件，且受 Git 跟踪状态和 .gitignore 限制。

git diff 不加参数：只看工作区和暂存区的差异

直接敲下 git diff，这个命令的默认行为非常明确：它只关心工作区（Working Directory）和暂存区（Index / Staging Area）之间的差异。简单来说，它就是用来回答“我手头改了哪些代码，但还没用 git add 存起来？”这个问题。这是日常开发中最频繁使用的场景。

需要明确的是，它不会显示已经暂存起来的修改，也完全不管远程仓库或本地分支的历史记录。

• 它的作用范围仅限于已被 Git 跟踪（tracked）的文件。那些新增但从未 git add 过的文件，默认不会出现在输出里（想查看它们，得靠 git status）。
• 如果暂存区是空的，那么 git diff 的输出也会是空的——但这绝不意味着工作区没有改动，只是所有改动都还“躺”在工作区，没进入暂存区而已。
• 命令的输出采用统一的 diff 格式，可以清晰地看到具体哪些行被添加、删除或修改，并附带一定的上下文，便于定位。

git diff --cached：对比暂存区和 HEAD

当你已经执行了 git add，把一部分修改放进了暂存区，接下来想确认“这些我准备提交的内容，和上一次提交（也就是 HEAD）相比到底有什么不同？”这时就该请出 git diff --cached 了（git diff --staged 和它完全等价）。

这个命令的核心价值在于：它是在执行 git commit 之前进行最终复核的利器，能有效避免把不该提交的内容误纳入版本历史。

• 如果暂存区里什么都没有，运行这个命令会直接报错提示 fatal: No changes added to commit。
• 它只专注于暂存区的内容，完全无视工作区当前的任何状态。哪怕你对同一个文件又做了新的修改，只要没再次 git add，就不会影响 --cached 的输出结果。
• 一个小坑：参数前面的两个横线 -- 不能省略。如果错写成 git diff cached，Git 会误以为你要比较工作区和某个叫 “cached” 的分支，结果多半是报错。

git diff HEAD：一次性看到所有未提交的变更

有时候你想快速了解，从上次提交到现在，本地总共积攒了多少改动（包括已暂存和未暂存的）。git diff HEAD 提供的正是这样一个“合并视图”——它比较的是“工作区 + 暂存区”与 HEAD 提交之间的差异。

不过，这里有个关键点需要注意：这个命令虽然方便，但它把工作区的修改和暂存区的修改“压扁”在一起展示了。你无法直接从输出中分辨出哪些改动已经暂存，哪些还留在工作区。这对于需要精细检查提交内容的场景来说，信息粒度就不够细了。

• 和之前一样，新增的、未被跟踪的文件仍然不会显示（想看它们，还是得用 git status -s，那些标着 ?? 的就是）。
• 如果一个文件在暂存区有修改，同时在工作区又有进一步的修改，那么 git diff HEAD 会同时显示出这两部分改动，但不会告诉你它们分别属于哪个区域。
• 从性能角度看，因为它需要综合计算两边的差异，所以通常会比单独的 git diff 或 git diff --cached 稍微慢一点点。

常见误操作和隐藏坑

很多开发者遇到的困惑，比如“为什么我明明改了文件，git diff 却什么也不显示？”，根源往往不在于命令用错，而在于对 Git 状态模型的理解存在偏差。

• 场景一：编辑了新文件但没 git add。正如前面提到的，git diff 默认会忽略它。排查时，请习惯性先用 git status 扫一眼全局。
• 场景二：只改变了文件权限（例如执行了 chmod）。Git 默认不追踪文件权限的变化，除非你显式配置了 core.filemode=true（这个配置在 Linux/macOS 上通常是默认开启的，而在 Windows 上默认关闭）。
• 场景三：换行符自动转换的“幽灵”改动。如果配置了 core.autocrlf，可能在跨平台协作时，git diff 会显示大量仅因行尾符号（CRLF/LF）不同而产生的差异，干扰对实际逻辑改动的判断。排查时，先确认相关配置。
• 场景四：.gitignore 并非万能。一个常见的误解是，文件被加入 .gitignore 后，Git 就完全不管了。实际上，git diff 不受 .gitignore 影响。如果一个文件已经被 Git 跟踪，那么即使后来把它加入了忽略列表，它的改动依然会出现在 diff 结果中。

说到底，在实际协作中，真正的难点往往不是记不住这几个命令，而是容易混淆“工作区 → 暂存区 → HEAD”这三层递进的边界。养成一个好习惯：每次敲下 git diff 之前，先在心里快速过一遍——“我当前想比较的，到底是哪两个状态？” 想清楚这个问题，比死记硬背任何参数都管用。