git status 这个命令，大概是每个用 Git 的人最早学会的三个命令之一：clone、commit、status。但用归用，真到“我到底改了什么、还有多少没提交”这种问题时，很多人还是会在终端里卡住——不是命令不会敲，而是不知道 Git 把改动放在了哪里、该问谁要。我见过太多次翻车现场：有人git diff看了半天没看到新文件，误以为改动丢了；有人在 IDE 里看到一堆临时文件，分不清哪些是本次该提交的；更惨的是直接git checkout .把一上午的修改冲掉，然后对着屏幕发呆。这篇就围绕“查看未提交的修改”这个核心场景，把工作区、暂存区、HEAD 三者之间的 diff 关系彻底讲透，顺便把文件未跟踪、行尾符、误删找回、分支合并中查看改动这类常见问题都带一遍。适合刚入坑的新手，也适合天天敲 git 但没空深究细节的老手。
1. 先搞懂“未提交的修改”到底存在哪：工作区、暂存区与 HEAD 的关系
1.1 三棵树模型：代码在“提交前”会经过哪几个位置
很多人对 Git 的理解还停留在“本地仓库 + 远程仓库”两个概念上，这导致他们看git status输出时会犯迷糊。实际上，一次提交之前，你的改动要经过两个中间位置：工作区（Working Directory）和暂存区（Staging Area / Index），最后才落到版本库里的 HEAD。
工作区就是你编辑器打开的那个目录，日常改文件都发生在这里。暂存区本质上是.git/index这个文件，它记录着“下一次提交要包含哪些内容”。HEAD 则是当前分支最近一次提交的指针，代表“仓库里已经固化的状态”。
理解了这个模型，再看未提交的修改就有三种情况：
- 工作区有改动，但没
git add，这叫 unstaged changes； - 已经
git add了，但还没git commit，这叫 staged changes； - 两者都有，一部分暂存、一部分未暂存，这是最常见的混合状态。
我用一个生活类比：工作区是超市货架，暂存区是购物车，HEAD 是已经结账拎回家的袋子。你在货架上拿了瓶酱油（修改了文件），放进购物车（git add），但还没结账（git commit）。这时候想盘点“我为这顿饭准备了什么”，光看购物车不够——货架上还有你犹豫要不要拿的东西。Git 的查看命令也是一样，得分别问工作区和暂存区。
1.2 为什么git status只能告诉你“有改动”，却回答不了“改了什么”
git status是查看未提交修改的入口，几乎所有人都会先敲它。但把它当成终点是个常见误区。git status默认输出的是文件级别的状态标签：modified、deleted、untracked，它告诉你哪些文件变了，却不告诉你每个文件里具体变了哪一行。
举个例子，你给config.py改了 30 处配置，git status只显示一行modified: config.py。你要的是这一行吗？不是，你要的是那 30 处具体改了什么。这时候必须用git diff才能看到内容级别的差异。
所以我的习惯是：git status只看目录、看全局，git diff看细节、看内容。两者配合才是完整的查询方案。等你熟练之后，可以给git status加上-s变成短格式，输出会精简到每行一个文件，像M config.py这样的标记，配合-b还能显示当前分支和上游分支的落后/超前信息。git status -sb是我在终端里敲得最频繁的命令，没有之一。
1.3 购物车类比：用git add把改动放进暂存区的意义
刚接触 Git 的人经常会问：为什么不能直接提交工作区的修改，非得先git add一下？这问题其实触及了 Git 设计的核心。暂存区让你有机会把一次提交拆成多个逻辑单元。
比如你同时在修一个 Bug 和一个新功能，改动了同一个文件里的两处不同逻辑。如果直接提交，两个用途的改动会混在一起，将来回溯历史时，别人没法只回滚 Bug 修复而不影响新功能。但有了暂存区，你可以git add -p把文件拆成多个 hunk，只暂存 Bug 修复那部分，先提交；新功能相关的改动留在工作区，下次再提交。
理解了暂存区的意义，你就会明白查看“未提交的修改”为什么必须区分两个 diff：
git diff：工作区 vs 暂存区，也就是你改了但还没git add的部分；git diff --cached（等价于git diff --staged）：暂存区 vs HEAD，也就是你git add了但还没git commit的部分。
这两个命令返回的内容合在一起，才是真正意义上的“从上次提交到现在你在本地干的所有事”。如果你想一步到位看总和，可以直接git diff HEAD，它对比的是工作区 vs HEAD，等价于把上面两个 diff 拼起来。下文我会把这组命令拆开细讲。
2. 一行命令看清所有未提交改动：git diff 全家族用法详解
2.1 基础组合：git status -sb + git diff + git diff --cached
先给一套可以无脑复制的组合拳。我每次坐到工位开始写代码前，如果开始前已经有一堆历史改动，我会先执行这三条：
git status -sb git diff git diff --cached第一条看整体态势：哪些文件改了，当前分支有没有落后远程。第二条看工作区未暂存的修改，第三条看暂存区里已记录但未提交的修改。
这套组合能覆盖 90% 的“查看未提交修改”需求。但注意，如果工作区非常脏，比如你改了 50 个文件，直接git diff的输出会非常长，刷屏刷到怀疑人生。这时候不要硬看，改用下一节介绍的精简参数。
还要提醒一个细节：如果你在一个刚克隆下来的仓库里执行git diff，却发现没有任何输出，别慌。这可能是因为你的工作区和暂存区都跟 HEAD 一致，也就是没有未提交的修改；也可能因为你的改动全部发生在未被跟踪的文件里。后面第 3 节会专门讲未跟踪文件的问题。
2.2 常用参数：--stat、--name-status、--word-diff、--check
查看未提交修改时，输出越长越难抓重点。我常用的参数组合如下：
git diff --stat git diff --name-status git diff --word-diff git diff --check--stat输出一个精简的文件列表，每行一个文件，后面带上增删行数的柱状图，一眼就能看出哪个文件动得最厉害。这个参数特别适合提交前的“体检”。--name-status更精简，只显示文件名和改动类型（A 新增、M 修改、D 删除）。
--word-diff是我个人非常喜欢的一个参数。默认git diff按行对比，如果你改了一长行文案里的一个词，diff 会显示整行被删除、整行被新增，看起来像大范围改动。加上--word-diff后，只有单词级别的变化会被标记成[-旧词-]和{+新词+}，特别适合检查文案、注释、文档这类容易被“行级 diff”误导的场景。比如你只把 README 里的一句提交通讯地址改成了新地址，普通 diff 可能显示几十行变化，word-diff 则清晰得多。
--check用来检查空白符错误，比如行尾多出来的空格、tab 和空格混用。这个参数不会直接影响查看进度的效率，但查“未提交修改”时我习惯顺手带上它：如果输出里有警告，说明这个 diff 里混着格式问题，提交前最好处理掉。
上面这些参数都能组合使用，比如git diff --stat HEAD看看从上次提交到现在所有未提交改动的统计信息。还有git diff --numstat会输出机器可读的增删行数，适合进一步写脚本处理。
2.3 按文件查看、分块暂存与复查：git diff --和 git add -p
全局 diff 太乱时，限定单文件是最好的办法。命令格式是：
git diff -- src/main.js git diff --cached -- src/main.js路径放在--后面，可以避免文件名和参数冲突。这个命令我第一次用的时候还犯过傻，直接写成git diff src/main.js，恰好在某些老版本 Git 里也能跑通，但从语义上说--才是标准写法。
拿到 diff 输出后，如果发现一部分改动该提交、一部分不该提交，我强烈建议你用git add -p进入交互式分块暂存。Git 会逐个 hunk 问你Stage this hunk [y,n,q,a,d,s,e,?]?，y 表示暂存，n 表示跳过，e 可以进入手工编辑模式微调。这样做的好处是提交粒度干净，但副作用是“未提交的修改”会变得横跨暂存区和工作区，查看时就要更仔细。
一个很实用的复查技巧：先用git add -p暂存一部分，再用git diff --cached确认暂存内容，再git diff确认自己还剩下哪些没暂存。这种“暂存前看、暂存后看”的循环能有效避免把临时调试代码提交上去。我曾经在一个配置分支里用这套流程拦截住了 3 处不该提交的本地路径和调试打印，否则 CI 会直接挂掉。
再强调一次速查逻辑：
| 命令 | 对比对象 | 解决的问题 |
|---|---|---|
git status -sb | 工作区 + 暂存区 vs HEAD | 快速浏览文件状态、分支信息 |
git diff | 工作区 vs 暂存区 | 查看未 add 的修改 |
git diff --cached | 暂存区 vs HEAD | 查看已 add 未 commit 的修改 |
git diff HEAD | 工作区 vs HEAD | 查看所有未提交修改的总和 |
git diff --stat | 同上 | 只关心文件维度统计 |
git diff -- <path> | 同上 | 只看某个文件 |
git add -p | 无 | 交互式分块暂存，控制提交粒度 |
3. 未跟踪文件、二进制文件、换行符：diff 里的四类“看不见的改动”
3.1 未跟踪文件与 intent-to-add 的妙用
很多人在终端里遇到的第一起“灵异事件”是：明明新建了一个文件，git diff却完全没反应。原因不复杂：git diff只对比 Git 已经追踪的对象。一个新建的、从未git add过的文件属于 untracked 状态，它连进入暂存区的资格都还没有，自然也没法被常规 diff 对比。
git status里会显示Untracked files:分类，但git diff不会。那有没有办法让未跟踪文件也出现在 diff 里？有两个办法。
第一个是git add -N <file>，也就是 intent-to-add，把一个文件“标记为打算添加”。执行之后，这个文件会被 Git 记录为已追踪但内容为空的新增文件，此时git diff就能显示出它的全部内容为新增。注意，git add -N只是打标记，并不会真的把文件内容放进暂存区，所以后续你还是得git add才能正常提交。我第一次用的时候差点直接 commit，还好习惯性检查了git status才发现它只是 intent-to-add 状态。
第二个办法是直接查看文件内容：cat path/to/file。如果只想知道“我新写的这个文件里面是什么”，没必要绕 diff 的弯子。更多时候，我会直接交给 IDE 看，因为 IDE 的差异视图天然包含未跟踪文件，不需要任何命令。
3.2 二进制文件与大文件：看不了内容就看统计
二进制文件、图片、PDF、打包产物这些，直接 diff 是输出乱七八糟的乱码，有些终端甚至会卡死几秒钟。查看这类“未提交修改”的合理姿势是放弃内容级对比，只问两个问题：这个文件有没有被改？改了多少？
git diff --stat和git diff --numstat在二进制文件上依然有效，它们会显示文件被修改，增删行数这一栏通常显示为Bin。如果你想更精细一点，可以用git diff --binary生成二进制的补丁文件，但这主要用于传输补丁，日常查看意义不大。
我踩过的一个坑是：往仓库里提交了一个超过 100MB 的模型文件，当时git status只显示它是 untracked，没当回事，直到推送时被远程仓库拒绝，才意识到大文件必须走 Git LFS。如果你在查看未提交修改时发现有个几十 MB 甚至几百 MB 的新文件，先别急着提交，评估一下是否该用 LFS 管理。
3.3 换行符与编码问题：为什么明明没改却满屏 diff
这是团队协作里最容易引发“幽灵 diff”的问题。Windows 上默认行尾是 CRLF，Linux/macOS 上是 LF。你从仓库拉下来的文件是 LF，编辑器在 Windows 上可能自动写成 CRLF，于是即使你没动过任何业务逻辑，git diff也会显示整个文件所有行都被改动。
解决办法分两步。第一步是统一 Git 的换行符策略，推荐设置.gitattributes文件，例如：
* text=auto *.sh text eol=lf *.bat text eol=crlf第二步是如果发现已经有一堆行尾符混乱的改动，先修复再谈查看。可以在仓库根目录执行：
git add --renormalize .这会把所有文件的换行符按.gitattributes规则重新规范化。执行完后你再git diff --stat，通常会发现历史遗留的“幽灵改动”消失了。
编码问题也是类似逻辑：文件从 GBK 转成 UTF-8 后，肉眼只看见几个中文字符变正常了，Git 却可能认为是整个文件重写。查看未提交修改时如果遇到“全文件 diff”但没有实际逻辑变化，先检查是不是换行符或编码问题，别急着怀疑别人动了你的代码。
3.4 已删除文件与重命名：git 如何呈现“删除”和“改名”
在 Git 里，删除和改名都会被当作一种修改。如果你rm了一个已跟踪文件，git status会显示deleted，此时用git diff HEAD能看到这个文件的完整内容被删除。如果删除前没有git add，则git diff也能看到删除差异；如果已经git add，则要git diff --cached才能看到。
重命名的情况稍特殊。Git 对重命名的默认处理方式是“删除旧文件 + 新增新文件”，只有在git diff -M或git status的输出里开启相似度检测，它才会聪明地识别出 rename。例如：
git diff -M --stat HEAD输出里会出现形如README.md -> docs/readme.md的内容。如果你在查看未提交修改时发现某个文件突然变成 deleted，但另一个地方又多了个 untracked 文件，大概率是重命名还没被 Git 识别出来。别慌，git add之后再git diff --cached -M看看，通常就正常了。
4. 误操作救急：checkout/reset 之后，未提交的修改还能找回吗
4.1 先备份再动手：stash 是改动最好的保险箱
查看未提交修改的时候，心态一般是“我只是看看，不会动”。但人有失手，马有失蹄。最常见的悲剧是：看到工作区太乱，想清理一下，敲了git checkout .或git reset --hard HEAD，然后所有未暂存修改瞬间蒸发。
我的原则是：只要有一丁点可能用到当前这些改动，在操作前先备份。备份不一定要多复杂，一条 stash 命令就够：
git stash save "backup before cleanup"git stash会把所有未提交的修改（包括已暂存和未暂存）保存成一个独立的存档，然后把工作区恢复成干净状态。这样你既得到了干净的目录，又能随时用git stash list查看存档，用git stash apply恢复修改。
这里有一个我踩过好几次的坑：git stash默认不带未跟踪文件。如果新增文件没被git add过，stash 会把它们留在工作区里，不会备份。所以需要带上前缀：
git stash -u-u就是--include-untracked，把未跟踪文件也一起存进去。还有一点，stash 的默认行为不包含被 ignore 的文件，如果你连.gitignore里忽略的临时文件都想备份，得用--all。但那个参数会把node_modules这种目录也塞进去，用时需谨慎。
4.2 reflog 与 fsck --lost-found 的恢复实践
如果你在没备份的情况下已经跑掉了改动，是不是就彻底没救？不一定。得分情况。
如果改动已经进入暂存区后被 reset 掉了，还能救。因为暂存区内容在 reset 之前是存在.git/index里的，执行git reset --hard HEAD会重建 index，旧 index 文件不会立即被删除。这时候可以试试：
git fsck --lost-found这个命令会扫描仓库里所有没有被引用到的对象，包括那些曾经被git add过的文件内容。扫描完输出一堆dangling blob，找到可疑的 blob，用git show <hash>查看内容，确认是你丢的文件后，把它复制出来。
如果是从未被git add过的工作区改动，恢复难度指数级上升。因为 Git 不会索引你没 add 的文件，文件系统层面也没备份。这种场景只能寄希望于编辑器的本地历史功能，或者手工 Ctrl+Z 往回找。所以备份的优先级永远高于事后恢复。
另一个更通用的恢复工具是git reflog。reflog 记录的是 HEAD 指针的移动历史，包括 checkout、reset、commit、merge 等操作。比如你 reset 掉了一个已经提交的 commit，用git reflog能看到 reset 之前的 commit hash，再用git cherry-pick <hash>或git reset --hard <hash>就能回到那个状态。不过 reflog 主要用于恢复“已提交但被移除”的内容，和未提交修改的恢复是两码事，但遇到连续误操作时经常一起配合用。
4.3 合并冲突、rebase 途中如何查看还剩哪些未提交修改
分支合并和 rebase 不需要记住 p 的坑位已经被改了 hash。单独说。
在合并或 rebase 过程中，git status会进入一个特殊状态：顶部会出现类似You have unmerged paths.的提示，并且文件状态从 modified 变成UU、AA、DD这类双字母标记。此时git diff和git diff --cached都不能完整反映所有冲突信息，需要用专门命令：
git diff --name-only --diff-filter=U这个命令只会列出处于冲突状态的文件，配合git diff <path>查看某个冲突文件的详细差异。如果你想在合并过程中看看“除了冲突之外，我还改了哪些文件”，可以加上HEAD对比：
git diff HEAD --name-status但要记住，合并期间的 diff 会同时显示两个分支各自的改动，跟平时查看自己的未提交修改含义不完全一样。看懂冲突区的三段式标记才是关键。
合并冲突解决完后，别忘了确认所有文件都已经git add再继续git merge --continue或git rebase --continue。我见过有人解决完冲突忘了 add，然后 Git 一直提示冲突未解决，人以为是 Git 出 Bug 了，实际上只是没标记为已解决。
5. IDE、AI Prompt 与团队工作流：怎么高效暴露“未提交的修改”
5.1 IDE 可视化：VS Code 与 IDEA 的本地改动面板
命令行再强大，有些场景还是 IDE 更直观。VS Code 的源代码管理面板（快捷键 Ctrl+Shift+G）会在左侧栏列出所有改动文件，点击任意文件就能看到左右分栏 diff，红色是删除，绿色是新增。而且它天然支持查看未跟踪文件，不像git diff那样默认跳过。这个面板还支持分块暂存，鼠标悬停在某个改动块上会出现 + 号，点击就能 stage。
IDEA 系工具则把入口放在Version Control工具窗口的Local Changes标签页里。它的 diff 视图比 VS Code 更精细，还能配合 IDE 的重构功能把未提交修改和最近的代码结构变化联动起来。我的经验是：日常写代码时用 IDEA 看，等到准备提交、处理复杂分支时用命令行git diff --stat复查一遍，两者互补。
5.2 把“git 问题”问对：写好一条 prompt 提示词的四个要素
Git 的学习成本不高，但出问题时的排查成本很高。很多人在搜索引擎或 AI 助手面前只会问一句“git 查看未提交的修改”，得到的答案往往是泛泛的命令列表，看完还是不知道哪条能解决自己的具体问题。
我后来发现一个规律：给 AI 提问 git 问题，本质也是写提示词。一条高质量的 prompt 至少包含四个要素：当前状态、目标对象、限制条件、期望输出格式。
举个例子。低质量的问法是：“git 怎么看没提交的东西？”这种问题模糊到无从回答。高质量的 prompt 是：
我当前在 feature/login 分支，
git status -sb显示 config.py 是 modified，还有一个新文件 login.js 是 untracked。我只想看 config.py 里还没git add的具体改动，按文件路径给出命令，并解释为什么不能用git diff --cached。
这个 prompt 里有明确的分支、明确的状态、明确的目标对象、明确的限制条件。你可以把类似的提问框架用在 git 安装配置、分支合并、SSH 认证失败等各种问题排查上。SSH 认证失败这类问题，甚至可以直接把安全提示贴进 prompt，让 AI 帮你判断是密钥权限问题还是远程主机密钥变更问题。
5.3 给 git 输出喂给 AI：把 git status -sb 作为上下文来分析改动
进阶一点的做法是：把命令输出本身当作上下文，给 AI 一个现场快照。比如你担心自己提交的内容混入了不该提交的文件，可以把以下内容发给 AI：
git status -sb ## feature/login M src/config.js ?? tmp/debug.log然后附加一句：请帮我判断哪些文件适合提交，哪些不适合，并说明理由。这种做法的好处是让 AI 基于真实输出而不是泛泛知识来做判断，准确率高得多。我自己就曾经用这种方式让 AI 发现了tmp/debug.log这类容易被忽略的临时文件，从而避免把它带进提交历史。
这个思路也适用于日常 Review：团队合作时，把自己分支的git diff --stat贴到群里，配合一句话说明本次改动范围，比甩一堆 diff 大图高效得多。
6. 常见问题速查：改动了却查不到、找不回、误删的排查表
6.1 问题速查表
| 现象 | 原因 | 解决思路 |
|---|---|---|
git diff没看到新增文件 | 文件是 untracked，diff 默认不追踪 | 用git status查看，或git add -N后再 diff |
| diff 输出显示整个文件被改动 | 换行符 CRLF/LF 不统一 | 配置.gitattributes，执行git add --renormalize . |
文件被git checkout .误删 | 未提交且未暂存的改动被覆盖 | 若曾git add可用git fsck --lost-found尝试恢复；未 add 则靠编辑器历史 |
git status显示 deleted + untracked 成对出现 | 重命名未被识别 | git add后使用git diff --cached -M |
| SSH 认证失败，远程仓库拉不下来 | SSH key 未配置或权限不对 | ssh -T git@example.com测试，检查~/.ssh权限 |
| 合并分支时查看未提交修改，状态全是 UU | 存在冲突 | git diff --name-only --diff-filter=U列出冲突文件 |
| reset 之后之前的 commit 丢了 | HEAD 被移动，commit 不再被引用 | git reflog找到旧 hash，git reset --hard <hash>恢复 |
大仓库里git diff响应很慢 | 输出太多或有大文件 | 用git diff --stat或限定路径git diff -- <path> |
6.2 快速定位思路：先看状态，再看差异，最后动文件
排查任何“未提交修改”相关的问题，我习惯按三步走：先git status -sb确认状态，然后git diff --stat看整体统计，最后针对具体文件git diff -- <path>深入内容。顺序不能反。
很多人一上来就git diff，输出一大堆根本看不完；或者一上来就翻 IDE，结果 IDE 因为文件太大卡到崩溃。命令行先扫描一遍，往往几秒钟就能锁定问题范围，再去 IDE 或文件编辑器里看具体内容。
另外，团队协作时还有两个很实用的前置检查：提交前git log --oneline -3看看最近的提交风格，避免提交信息风格不统一；推送前git status -sb确认本地分支没有落后远程，否则推送的时候容易先被git pull打断节奏。
6.3 实战心得：几个我后来才想明白的细节
第一，git diff的默认对比对象是“工作区 vs 暂存区”，不是工作区 vs HEAD。这个认知比命令本身重要得多，因为它决定了你看到的信息来源。想对比工作区 vs HEAD，必须显式写HEAD。
第二，git add -N是个小众但好用的参数，它让未跟踪文件进入 diff 视野，又不会真的把文件内容暂存。适合那种“先看看全貌，但暂不决定提交哪些”的场景。
第三，真正常见的“未提交修改查不到”，不是命令不会写，而是对三种状态（untracked、modified、staged）定义不清。把状态搞清楚，命令就是顺水推舟的事。
我个人在实际操作中的体会是：查看未提交的修改这件事，本质上是给代码仓库做一次“提交前体检”。与其背一堆命令，不如先培养一个肌肉记忆——进到仓库里先敲git status -sb，再按需敲git diff --stat，最后才针对性地打开具体文件的 diff。危险操作前的那三秒，足够救回好几次通宵写出来的代码了。
