最近在 kiro 项目帮同事排查代码提交问题他一脸疑惑地跟我说“我改了一整天怎么查看未提交的修改时git status里只有两个文件”我过去看了一眼发现他改的配置文件被.gitignore忽略了Git从头到尾就没跟踪过它。这个场景太典型了几乎每个用过Git的人都会在某个阶段被“未提交的修改”这个概念坑过一次。后来我把自己平时排查“git查看未提交的修改”的整套思路整理了一遍又结合最近团队里用得越来越多的AI提示词prompt工作流发现两者搭配起来效率提升非常明显。这篇内容就把这东西完整写出来适合刚学Git的新手也适合那些“用了好几年Git但遇到diff还是靠猜”的老朋友。先说清楚边界这篇文章不打算重复git安装教程默认你已经装好了Git配置好了user.name和user.email仓库也初始化了。如果你连这些都没搞定建议先花十分钟把环境弄好回来再看下面的内容。1. 先搞懂Git的三个区域后面所有命令才不会用错1.1 工作区、暂存区、版本库分别装了什么很多人在“查看未提交的修改”这件事上栽跟头归根结底是没有理解Git的三个状态区域。我用一个类比来解释假设你是个写手。工作区Working Directory就是你电脑上打开的草稿本所有改动都先发生在这里。暂存区Staging Area / Index相当于你整理好的“待提交清单”你把某些改动挑出来放进去告诉Git“我准备提交这些”。对应git add操作。版本库Repository是正式的存档库每次git commit之后改动的快照就永久记录在这里。“未提交的修改”严格来说包括三种一是工作区里相对暂存区的修改改完还没add的二是暂存区里相对最近一次提交的修改已经add但还没commit的三是工作区里那些从未被Git跟踪过的新文件untracked files。搞清楚这三个“场地”你才能真正理解为什么有时候执行git diff屏幕上什么都没有——因为你的改动早就被你git add进了暂存区而默认的diff根本不查那个位置。1.2 “未提交的修改”到底包含哪些内容按我日常经验可以归成五类已修改未暂存modified, not staged改过但没执行git add体现在工作区。已暂存未提交staged执行过git add但没执行git commit体现在暂存区。未跟踪文件untracked新建的文件Git之前从未见过它。已删除未暂存deleted把某个文件删了Git知道“这个人以前存在现在没了”。重命名与复制Git在内容相同的情况下会识别重命名但需要diff带着特定参数去看。1.3 为什么新手总是“看漏”修改看漏修改的三个常见原因我每次排查同事问题时几乎都会碰到。第一文件被.gitignore忽略了。你以为Git在记录其实它根本没关心过这个文件。我那位同事改的就是这种情况配置文件在.gitignore里改一万遍status也不会显示。第二文件名大小写问题。在macOS或者Windows上默认文件系统大小写不敏感你把README改成readmeGit可能毫无反应因为你改的只是文件名大小写内容没变。第三行尾符CRLF/LF差异。Windows上自动转换换行符明明内容没变git status却显示一大片文件被修改。这种情况需要配置core.autocrlf或者给仓库加.gitattributes统一行尾。这三个问题都挺隐蔽不是简单命令能解决的但至少你要知道“看不到修改”不等于“没有修改”。2. 第一层检查git status 看清文件层面发生了什么2.1 完整状态输出怎么读大多数时候我建议先执行git status而不是直接git diff。status的功能是告诉你“哪些文件发生了什么状态变化”它不展示具体每行改了啥信息密度反而最可控。一个典型的输出大概长这样$ git status On branch main Your branch is up to date with origin/main. Changes to be committed: (use git restore --staged file... to unstage) new file: docs/architecture.md modified: src/service/user_service.py 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: src/service/order_service.py deleted: tests/old_test.py Untracked files: (use git add file... to include in what will be committed) notes/debug_todo.md读它的顺序也有讲究。首先看分支名和你本地落后还是领先远程其次看“Changes to be committed”这部分是已经暂存、就差commit的再看“Changes not staged for commit”这部分是改过但还没add的最后是Untracked files一堆新出现的文件。很多人只盯着中间那块看结果漏掉了最下面的新文件。2.2 --short模式想快速扫一眼推荐这个如果你跟我一样懒得看长文本git status --short简写git status -s会按文件列出状态每一行两个字符位。第一位表示暂存区的状态第二位表示工作区的状态。常用标记有M已修改A新添加到暂存区D已删除R重命名?未跟踪空格这个位置没有变化所以“M ”表示该文件已暂存但未提交“ M”表示工作区里改了但还没暂存“MM”就是两个位置都改了很典型的一种状态。git status -s的输出干净利落配合git status完整版一起看基本上能把所有文件级别的情况掌握清楚。2.3 我常用的几个status变体git status --ignored可以列出被忽略的文件排查.gitignore问题的时候非常管用。git status --branch可以显示当前分支的追踪信息。比如你怀疑某些文件被忽略又不想去翻.gitignore规则文件直接跑一眼git status --ignored所有被忽略的文件和目录都会列出来。我自己的习惯是刚开始干活时跑一次git status -s把基线记录下来干完活再跑一次两相对比就知道这期间到底新增了哪些文件。这个习惯成本极低但对防止“漏提交”非常有效。3. 第二层检查git diff 定位每一行改动3.1 三个diff变体你必须分清楚如果说status是目录索引那git diff就是正文它告诉你具体哪一行加了、哪一行删了。这里最大的坑就是三个变体的比较范围。我列个表直接背下来命令比较对象最常见的困惑git diff工作区 vs 暂存区add之后跑它显示为空git diff --staged或--cached暂存区 vs 最近一次提交没add的时候跑它为空git diff HEAD工作区暂存区 vs 最近一次提交最全面但也最杂重点记住默认的git diff只关心“工作区和暂存区之间”的差异你已经add过的内容要用--staged去看想要一次性看到“我这次提交相比HEAD改了什么”就用git diff HEAD。3.2 把diff的输出控制在你想要的范围内默认全量diff的输出可能非常长尤其是改了多个文件的时候。我建议几个参数配合使用git diff --stat只显示每个文件的增删统计比如“120, -34”适合提前评估改动规模。git diff file只看某个指定文件。git diff -w忽略空白字符的变化对复制粘贴后格式变化的场景很实用。git diff --word-diff按词而不是按行来显示差异看长段落文字、JSON、Markdown的改动特别好用。另外配合--coloralways可以把颜色带进管道方便在脚本里使用。3.3 提交前一定先跑diff这个坑我踩过我有一次把“调试用的console.log”和“临时改的数据库地址”一起提交到了主干分支第二天项目组在联调时发现所有请求打到了测试库。原因就是提交前没有认真看diff只顾着看status文件列表觉得“文件都对直接commit吧”。从那以后我给自己定了个铁规矩git commit之前至少跑一次git diff HEAD逐段扫一遍重点看有没有去掉的调试语句、写死的路径、临时的逻辑开关。这个习惯比任何Git技巧都值钱。4. 实战演练几种典型场景从排查到收尾4.1 改了一堆代码但没stage先看再说场景你改了src/service/user_service.py和src/service/order_service.py还没add。这时候直接执行git status -s git diff src/service/user_service.py第一条命令确认改动的文件范围第二条命令看具体某个文件的差异。确认无误后git add src/service/user_service.py src/service/order_service.py git diff --staged这里git diff --staged的作用是把你即将提交的内容做一个“最终审查”确认暂存区里的内容就是你真正想提交的。4.2 add之后又改了文件混合状态的处理这个场景特别常见你把一个文件add了然后又改了它几行。这时git status会出现类似“MM”的输出说明暂存区里有一个版本、工作区里又有更新的修改。处理方式有两种。第一种如果你对刚才add的版本不看了直接用git add把最新内容覆盖进暂存区然后提交。第二种如果你想区分查看两个版本git diff看工作区相对暂存区的新改动git diff --staged看之前暂存的内容对比HEAD的改动。这样的话你就能清楚地区分“上一版”和“最新版”分别改了什么。4.3 改乱了想回到之前的状态Git提供了两条路丢掉工作区改动或者把暂存区内容撤回来。# 丢弃工作区对某个文件的修改危险操作文件内容会被覆盖 git restore file # 或老版本写法 git checkout -- file # 把已暂存的内容撤回到工作区 git restore --staged file注意git restore file会直接丢弃工作区里的未提交修改不可恢复。一旦你跑了这个命令想靠Git找回是不可能的。所以我在执行之前通常会先看一眼git diff确认里面没有需要保留的内容。如果你想找的是“我昨天改的东西不小心没提交”那要换一个命令去看比如git reflog或者git log那是另一个话题。但记住一个基本方向还没commit的改动在reflog里多半找不到所以平时养成频繁提交、提交前看diff的习惯最重要。4.4 提交前最后确认三条命令的组合拳我现在每次提交前固定执行这三条git status -s git diff --stat git diff --stagedstatus -s检查有没有遗漏的untracked文件diff --stat看整体增删量diff --staged逐行审查将要提交的内容。三条命令下来信息量刚刚好不会漏也不会糊。5. 用提示词(prompt)解放双手让AI帮你读diff、写提交信息、排错5.1 为什么在Git工作流里值得引入prompt很多同事觉得Git命令记不住各种参数组合太多结果每次都要翻文档。我如今的做法是把一部分“记忆负担”交给AI合理设计提示词prompt让AI生成命令、解释diff、甚至直接写提交信息。先说明这不是让你放弃理解Git原理而是把“命令查完却不知道自己在干嘛”的时间浪费省下来。当你需要AI帮忙操作的时候你至少有基础判断力去验证AI给的命令对不对。理解原理永远是第一位的prompt只是放大器。5.2 一个基础模板让AI帮你生成精确的Git命令我常用的最基础prompt长这样你是一个Git专家。我在一个Git仓库里当前分支是main。 请帮我生成以下命令并解释每一条的作用 1. 查看所有未提交的修改包括未暂存和已暂存的。 2. 查看未暂存修改的具体内容。 3. 查看已暂存修改的具体内容。 4. 查看工作区和暂存区相对最近一次提交的全部差异。 输出请以列表形式给出每条后面附一行解释。这个prompt的写法有几个要点给出了角色Git专家、具体的场景哪个分支、具体任务四条命令、输出格式列表加解释。AI给的命令几乎不会错因为这类需求太标准了。5.3 用prompt读diff代码审查式提问当你有一大段diff输出不知道该不该提交、或者想快速找到问题的时候可以把diff正文粘贴给AI然后这样问以下是某个分支相对main的未提交diff [在这里粘贴git diff HEAD的输出] 请帮我做一次代码审查 1. 有没有明显bug或逻辑问题 2. 有没有忘了删除的调试代码、写死的路径、临时开关 3. 有没有性能隐患 4. 每个文件的改动摘要用中文回答。 请逐条列出最后给一个是否适合提交的建议。这个prompt非常实用。但注意一个合规细节粘贴的diff如果包含公司内部敏感代码或凭据请先清理一下。不要因为图方便就把密钥、内网域名、客户数据喂给外部AI服务。自己判断是否在允许范围内。5.4 让AI帮你解决diff冲突合并分支时出现冲突很多人第一反应是头大。给AI的prompt我一般这样写我在合并分支时遇到以下冲突这是冲突文件的当前内容 [粘贴冲突文件内容包含 HEAD等标记] 请帮我分析冲突的双方逻辑给出合并建议并直接输出合并后的完整文件内容。 如果存在会改变行为语义的冲突请单独标注出来。这类prompt起作用的前提是你给AI的上下文足够完整。冲突标记本身自带“双方版本”AI是能理解的但不一定懂你的业务意图所以给它加上“这段代码是订单价格计算模块”之类的业务背景效果会好得多。5.5 自动生成提交信息commit message每次写提交信息也很费脑子。我用这样一个模板根据以下diff帮我写一条符合Conventional Commits规范的git commit message。 要求 - type从feat/fix/refactor/docs/chore/test中选择理由写在括号里 - subject不超过50个字符中文 - 正文用列表列出3到5条关键改动 diff如下 [粘贴git diff --staged的输出]当diff比较小的时候这个模板非常高效。diff过大时建议先跑一下git diff --staged --stat只看统计再挑重点文件单独粘贴避免信息量过大AI抓不住重点。5.6 提示词(prompt)执笔的核心原则还有一点实战经验实践下来一个有效的prompt大概包含三个部分角色与上下文告诉AI你是谁、在做什么、仓库里大致是什么项目。任务描述明确要让AI输出什么是命令、分析、还是文件内容。输出约束指定格式比如列表、中文、代码块、不要解释、限制字数。如果AI给你的结果不对不需要重新开聊天直接追加“请重点检查xxx”或者“换一种输出格式”就是最常见也最有效的修正方式。另外一个经验是让AI“先列命令再执行命令最后解释命令”。不要让它在同一条消息里既给命令又瞎编结果。我见过太多人把AI当搜索引擎问了一句“git怎么查看未提交的修改”AI回了十个命令水平参差不齐还不如直接看文档。6. 踩过的坑和几个实用技巧6.1 忽明忽暗的“git status显示正常”假象有时候你明明改了文件git status就是一片干净。多数情况下是前文说到的.gitignore。怎么验证跑git status --ignored它会列出被忽略的文件或者用git check-ignore -v 文件命令知道具体是哪一行规则把这个文件忽略了。这个命令调试.gitignore特别好用。6.2 diff里中文乱码在Windows还有老版本Git里git status和git diff遇到中文路径或中文内容可能出现乱码。我建议在Git配置里设置git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8第三第四个配置主要解决提交信息里的中文显示问题。改完之后大部分中文乱码都能缓解。6.3 .gitignore不生效新加进.gitignore的规则对已经在Git跟踪中的文件是无效的。Git会继续跟踪那些已经被add过的文件。正确做法是git rm -r --cached 文件或目录 git add . git commit -m chore: stop tracking ...--cached参数只把文件从跟踪记录里移除但保留本地物理文件。跑完这套操作后新的.gitignore规则才会真正生效。6.4 一堆文件改动时怎么快速过滤出关键改动改了几十个文件的时候直接git diff HEAD能把终端刷到怀疑人生。我的建议是组合使用# 只看统计信息 git diff HEAD --stat # 过滤掉测试文件只看src目录 git diff HEAD -- src/ # 排除某个目录 git diff HEAD -- . :!docs/最后这个写法是pathspec的exclude语法我用了很久才发现能这么用真的很方便。另外交替使用git diff HEAD --name-only可以只列出修改过的文件路径配合循环命令可以批量处理。6.5 三个提高日常效率的小习惯第一个给git配置别名。比如git config --global alias.st status把git status缩短为git st更狠一点的人会把git check-ignore缩成git whyignore查忽略原因变得顺手。第二个提交前用git diff --check这个命令会找出常见的空白错误比如行尾空格、空文件末尾没有换行符很多CI检查的正是这些。第三个养成git status -s的肌肉记忆别总看完整版简短输出足够日常用。最后分享一个我自己的习惯每次提交前不管有多着急我都会强制自己跑一遍git diff HEAD --stat把改动规模控制在能看懂的范围内。如果diff输出超过一屏我会拆小提交而不是硬着头皮把所有文件揉进一次commit。这种做法让我少踩了很多“改错了不知道回退到哪儿”的坑。如果你刚接触Git建议从今天开始就用这套组合status看文件、diff看内容、prompt辅助读代码、提交前复查。坚持一个月你会发现自己对代码仓库的把控能力完全不一样。