这种不确定感是每个开发者都会遇到的问题。
其实，想看清工作区和暂存区这两者之间的具体差异，你只需要一个核心命令：git diff。通过它和它的一个常用参数，就能精确地查看每一行代码的变动，让你在提交前做到心中有数。
git status：一个全局视角
在深入代码行级别的差异之前，我们通常会先用 git status 命令看一个全局。它能告诉你哪些文件发生了变化，以及它们目前处于什么状态。
比如，你修改了 main.js 文件，git status 会告诉你：
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: main.js
这说明 main.js 在你的工作目录（Working Directory）里被修改了，但这些修改还没有被添加到暂存区（Staging Area）。
git status 解决了“哪些文件被改了”的问题，但它不回答“文件里到底改了什么”。要回答这个问题，就需要 git diff 登场了。
git diff：查看尚未暂存的修改
当你直接在终端里输入 git diff 时，Git 会为你比较 工作目录和 暂存区之间的差异。
简单来说，它显示的是“你已经做了，但还没 add 的修改”。
假设 main.js 原本只有一行代码：
// version 1
你把它改成了：
// version 2
console.log('hello');
此时运行 git diff，你会看到类似下面的输出：
--- a/main.js
+++ b/main.js
@@ -1 +1,2 @@
-// version 1
+// version 2
+console.log('hello');
这里的 - 号代表“从暂存区的版本中移除这一行”，而 + 号则代表“在工作目录的版本中添加了这一行”。通过这个输出，你可以清晰地看到所有还未暂存的修改。
git diff --staged：查看已暂存的修改
现在，我们把刚才的修改添加到暂存区：
git add main.js
完成之后，如果再次运行 git diff，你会发现它什么也不显示了。这是因为你的工作目录和暂存区现在的内容已经完全一样了。
那么，如何查看我们刚刚添加到暂存区、准备提交的那些内容呢？
答案是使用 git diff --staged (或者它的另一个别名 git diff --cached)。这个命令比较的是 暂存区和**上一次提交（HEAD）**之间的差异。
它显示的是“你已经 add 了，准备 commit 的修改”。
运行 git diff --staged，你会看到和上一步完全相同的输出，因为它展示的正是你刚刚暂存的那些改动。在执行 git commit 之前，运行这个命令来做最后一次检查，是一个非常专业的习惯。
场景演练：当两个区域都存在修改
为了彻底搞懂，我们来看一个更常见的复杂场景。
接上一步，main.js 的修改已经被暂存。现在，你又在工作目录里对它做了第二次修改，比如为其增加了一行注释：
// version 2
// This is a test
console.log('hello');
此时，main.js 这个文件同时存在“已暂存的修改”和“未暂存的修改”。运行 git status 也会明确提示这一点。
在这种情况下：
- 运行 git diff，它只会显示第二次的修改，也就是那行新增的注释。因为它只关心工作目录与暂存区的差异。
- 运行 git diff --staged，它则会显示第一次的修改（版本 1 到版本 2 的变化）。因为它只关心暂存区与上次提交的差异。
通过这两个命令的组合，无论你的修改有多复杂，都能被清晰地划分和审阅。
总结：养成清晰的提交习惯
现在，我们可以建立一个清晰、可靠的版本控制流程，避免混乱。
- 编码修改：在你的工作目录中修改文件。
- 查看状态：运行 git status，了解哪些文件被改动了。
- 审查修改：运行 git diff，查看所有尚未暂存的修改，确保没有多余的调试代码。
- 添加暂存：使用 git add <file> 将确认无误的修改添加到暂存区。我们建议精确地添加文件，而不是总用 git add .。
- 审查暂存：运行 git diff --staged，对即将提交的内容做最后一次审查。这步至关重要。
- 提交：运行 git commit，并撰写一条清晰的提交信息。
养成这个习惯，能极大地提升代码质量和协作效率，让你的每一次提交都精准且自信。