如何比较暂存区与最新提交的差异？

这时，你需要一个精确的命令来回答这个问题。这个命令就是 git diff --staged。它能清晰地展示出暂存区（Staging Area）相对于上一次提交（HEAD）的所有差异，让你在提交前做到心中有数。

核心命令：git diff --staged

当你想要查看那些已经被 git add、即将被打包进下一次提交里的具体代码变更时，git diff --staged 是最直接、最准确的命令。

git diff --staged

这个命令比较的是“索引（Index）”和“HEAD”之间的差异。在 Git 的语境里，索引就是暂存区的另一种叫法，而 HEAD 则通常指向你当前所在分支的最新一次提交。因此，这个命令的输出结果，就是你下一次 git commit 将会创建的快照内容。养成在提交前执行此命令的习惯，是保证提交历史清晰、可追溯的第一步。

辨析：--staged 与其他 diff 命令有何不同？

git diff 家族的命令看起来很相似，这也是许多开发者感到困惑的地方。要彻底弄清楚，关键在于理解 Git 的三个核心区域：工作区（Working Directory）、暂存区（Staging Area）和版本库（Repository，以 HEAD 为代表）。

场景一：比较工作区与暂存区

如果你想知道自己做了哪些修改，但还 没有通过 git add 命令将它们暂存起来，那么应该使用不带任何参数的 git diff。

git diff

它的作用是比较“工作区”和“暂存区”的差异。这可以帮你快速看到那些“尚在处理中”的修改，以便决定是否要将它们添加到暂存区。

场景二：比较暂存区与最新提交

这正是我们讨论的核心场景。当你执行了 git add 之后，想确认即将提交的内容是否准确无误，就需要 git diff --staged。

它比较的是“暂存区”和“HEAD”的差异。输出的内容，就是你为下一次提交精心准备的“包裹”，不多不少。

场景三：比较工作区与最新提交

还有一种情况是，你可能想一步到位，看看当前工作目录里的所有文件（无论是否已暂存）与最新一次提交相比，总共发生了哪些变化。这时，你需要 git diff HEAD。

git diff HEAD

它比较的是“工作区”和“HEAD”的差异，可以看作是前两种 diff 场景的总和。这个命令能让你对当前分支的所有“未提交”状态有一个全局的了解。

一个关键回顾：三者的关系

为了帮你建立更清晰的认知模型，我们可以这样总结这三个命令的对比范围：

• git diff：工作区 vs 暂存区（查看尚未暂存的修改）
• git diff --staged：暂存区 vs HEAD（查看已暂存、即将提交的修改）
• git diff HEAD：工作区 vs HEAD（查看所有未提交的修改，无论是否暂存）

理解这三者的区别，是高效且无误地使用 Git 的基础。

别名：--cached

你可能还会看到 git diff --cached 这个命令。实际上，它和 git diff --staged 是完全等价的。

git diff --cached

两者可以互换使用，效果没有任何区别。Git 同时提供这两个选项，主要是因为“暂存区”在内部也被称为“缓存（cache）”。选择你个人更习惯记忆和使用的那一个即可。

为什么提交前检查很重要？

在执行 git commit 前多花几秒钟运行一次 git diff --staged，是一个投入产出比极高的开发习惯。

它能有效避免将无用的 console.log、临时配置文件、甚至是密码等敏感信息意外提交到版本库中。同时，清晰地了解本次提交所包含的全部内容，也能帮助你撰写出更准确、更有意义的提交信息（Commit Message），这对于团队协作和后续的代码维护至关重要。

总而言之，通过 git diff --staged 进行提交前的最终审查，不仅是对自己负责，也是对团队和项目的尊重。它将琐碎的修改转化为一次次清晰、独立的变更记录，构成了高质量软件项目的基石。