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 修复那部分先提交新功能相关的改动留在工作区下次再提交。理解了暂存区的意义你就会明白查看“未提交的修改”为什么必须区分两个 diffgit 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 上默认行尾是 CRLFLinux/macOS 上是 LF。你从仓库拉下来的文件是 LF编辑器在 Windows 上可能自动写成 CRLF于是即使你没动过任何业务逻辑git diff也会显示整个文件所有行都被改动。解决办法分两步。第一步是统一 Git 的换行符策略推荐设置.gitattributes文件例如* textauto *.sh text eollf *.bat text eolcrlf第二步是如果发现已经有一堆行尾符混乱的改动先修复再谈查看。可以在仓库根目录执行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 cleanupgit 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 的文件文件系统层面也没备份。这种场景只能寄希望于编辑器的本地历史功能或者手工 CtrlZ 往回找。所以备份的优先级永远高于事后恢复。另一个更通用的恢复工具是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-filterU这个命令只会列出处于冲突状态的文件配合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 的源代码管理面板快捷键 CtrlShiftG会在左侧栏列出所有改动文件点击任意文件就能看到左右分栏 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 一个现场快照。比如你担心自己提交的内容混入了不该提交的文件可以把以下内容发给 AIgit 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没看到新增文件文件是 untrackeddiff 默认不追踪用git status查看或git add -N后再 diffdiff 输出显示整个文件被改动换行符 CRLF/LF 不统一配置.gitattributes执行git add --renormalize .文件被git checkout .误删未提交且未暂存的改动被覆盖若曾git add可用git fsck --lost-found尝试恢复未 add 则靠编辑器历史git status显示 deleted untracked 成对出现重命名未被识别git add后使用git diff --cached -MSSH 认证失败远程仓库拉不下来SSH key 未配置或权限不对ssh -T gitexample.com测试检查~/.ssh权限合并分支时查看未提交修改状态全是 UU存在冲突git diff --name-only --diff-filterU列出冲突文件reset 之后之前的 commit 丢了HEAD 被移动commit 不再被引用git reflog找到旧 hashgit reset --hard hash恢复大仓库里git diff响应很慢输出太多或有大文件用git diff --stat或限定路径git diff -- path6.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。危险操作前的那三秒足够救回好几次通宵写出来的代码了。
Git查看未提交修改全攻略：从status到diff再到误删恢复
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 修复那部分先提交新功能相关的改动留在工作区下次再提交。理解了暂存区的意义你就会明白查看“未提交的修改”为什么必须区分两个 diffgit 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 上默认行尾是 CRLFLinux/macOS 上是 LF。你从仓库拉下来的文件是 LF编辑器在 Windows 上可能自动写成 CRLF于是即使你没动过任何业务逻辑git diff也会显示整个文件所有行都被改动。解决办法分两步。第一步是统一 Git 的换行符策略推荐设置.gitattributes文件例如* textauto *.sh text eollf *.bat text eolcrlf第二步是如果发现已经有一堆行尾符混乱的改动先修复再谈查看。可以在仓库根目录执行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 cleanupgit 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 的文件文件系统层面也没备份。这种场景只能寄希望于编辑器的本地历史功能或者手工 CtrlZ 往回找。所以备份的优先级永远高于事后恢复。另一个更通用的恢复工具是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-filterU这个命令只会列出处于冲突状态的文件配合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 的源代码管理面板快捷键 CtrlShiftG会在左侧栏列出所有改动文件点击任意文件就能看到左右分栏 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 一个现场快照。比如你担心自己提交的内容混入了不该提交的文件可以把以下内容发给 AIgit 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没看到新增文件文件是 untrackeddiff 默认不追踪用git status查看或git add -N后再 diffdiff 输出显示整个文件被改动换行符 CRLF/LF 不统一配置.gitattributes执行git add --renormalize .文件被git checkout .误删未提交且未暂存的改动被覆盖若曾git add可用git fsck --lost-found尝试恢复未 add 则靠编辑器历史git status显示 deleted untracked 成对出现重命名未被识别git add后使用git diff --cached -MSSH 认证失败远程仓库拉不下来SSH key 未配置或权限不对ssh -T gitexample.com测试检查~/.ssh权限合并分支时查看未提交修改状态全是 UU存在冲突git diff --name-only --diff-filterU列出冲突文件reset 之后之前的 commit 丢了HEAD 被移动commit 不再被引用git reflog找到旧 hashgit reset --hard hash恢复大仓库里git diff响应很慢输出太多或有大文件用git diff --stat或限定路径git diff -- path6.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。危险操作前的那三秒足够救回好几次通宵写出来的代码了。