说实话很多人在使用 Git 一段时间后还是会不自觉地就把git add当成“保存文件”来理解。编辑器里按下 CtrlS内容落盘到工作区执行 git add很多人以为文件“已经提交到仓库了”其实这才刚走了一半。添加文件到暂存区是整个 Git 提交链条里最基础、也最容易被忽略的一步偏偏这步决定了你提交历史的干净程度。我见过太多提交记录里混着临时日志、编译产物和半成品代码根源基本都是暂存区没用好。如果你搞懂了暂存区是什么、add 到底做了什么、误加之后怎么补救你会发现 Git 的可控性比想象中高很多。这篇文章就把“添加文件到暂存区”这件事拆开聊从内部原理到日常命令再到多人协作里真正会踩的坑都过一遍。1. 先说清楚暂存区到底是一个什么样的存在1.1 工作区、暂存区、版本库三个区域各管各的Git 的日常操作其实是在三个区域之间搬东西工作区、暂存区、版本库。工作区就是你在磁盘上看到的文件目录你平时打开编辑器改的就是这里的内容暂存区是隐藏在 .git 目录里的一个状态记录区它不保存文件的完整副本而是保存“下一次提交准备记录哪些变更”版本库则存放了历史提交以及对应的完整文件快照。很多新手一开始只理解“改了文件、提交一下”这个流程把 git add 和 git commit 当成两个连续动作。实际上正是那个夹在中间的暂存区才让 Git 可以做到“一次提交只包含你希望包含的内容”。举个例子你一个下午改了三个功能点但不希望把它们揉进同一条提交记录这时候暂存区就是你的分拣台。你可以分三次 add 三个文件再分三次 commit得到三条清晰的提交记录。用生活一点的说法工作区是厨房台面菜都摆在那暂存区是备菜盘你决定哪几样先进锅版本库才是最终上桌的菜。git add 就是从台面上挑菜装进备菜盘的过程。1.2 git add 并不是“保存文件”而是登记变更要理解暂存区就要知道 git add 执行时内部发生了什么。很多人以为 add 会把文件复制进某个目录其实不是。当你执行git add README.md的时候Git 会做几件事先读取 README.md 的当前内容计算出一个哈希值把这个内容作为 blob 对象写进 .git/objects 目录然后更新暂存区索引文件 .git/index在这个索引里登记一条记录内容大致包括文件路径、文件权限模式、以及刚才算出来那个 blob 的哈希值。这个时候工作区里的 README.md 本身没有任何变化你也不会在 .git 里看到一个叫 README.md 的文件副本。真正被记录下来的是“这个文件在当前这一刻的内容是什么”的引用信息。索引文件相当于一份清单清单上写着下次提交时需要把哪些路径关联到哪些对象。这带来一个很关键的特性如果你在 add 之后又修改了工作区文件暂存区里记录的仍是上一次 add 时的内容不会自动跟着变。如果你不重新 add 就直接 commit提交里包含的就是旧版本而不是你最后一次保存的内容。这个坑几乎每个 Git 新手都会踩一次以后看到“Changes not staged for commit”的提示时第一反应应该是文件在工作区变了但暂存区还没有跟上。1.3 为什么 Git 非要搞一个暂存区有人可能会问既然最终都要提交为什么不直接 commit省掉 add 这一步这个问题背后其实是对 Git 设计哲学的理解提交是面向“逻辑单元”的而不是面向“时间点”的。没有暂存区的话所有工作区改动会一股脑进入下一次提交。那你可能一次提交里既修了 bug、又加了功能、还调整了格式将来回滚时根本不知道该回到哪个状态。暂存区允许你在提交前对变更做筛选和编排让每条提交都尽量保持单一职责。另外暂存区也为提交前检查提供了机会。你可以先 add 一部分文件然后通过git diff --cached仔细查看即将进入提交的内容确认没有遗漏、没有误加。这种“先审阅、再提交”的习惯在多人协作里尤其重要因为提交历史一旦推送出去改起来就麻烦得多。2. 最基础也最常用的 add 命令带你逐一过一遍2.1 精确添加什么时候用 git add 具体路径最朴素的做法就是指定文件路径git add README.md git add src/index.js src/utils/format.js git add docs/指定单个文件、多个文件或者整个目录Git 都支持。目录会被递归处理目录下所有未忽略的文件都会被加入暂存区。这种写法的好处是精确、可控适合你的改动本来就很零散、只需要提交其中一部分文件的时候。比如你同时改了接口文档和业务代码但想分两个提交就先 add 文档提交一次再 add 代码提交一次。有一点要注意路径里如果包含空格比如git add my file.txtshell 会把空格当成参数分隔符这时需要给整个文件名加引号git add my file.txt如果文件名本身以短横线开头比如-notes.txt直接写会被 Git 当成命令选项。提前用--分隔参数即可git add -- -notes.txt这种边界情况平时不常见但遇到了很容易卡住记下来能省不少时间。2.2 git add .、-A、-u三个兄弟到底怎么选日常讨论度最高的三个形式是git add .、git add -A和git add -u。它们不是完全等价很多分歧都来自这里。命令作用范围是否包含新建文件是否包含删除文件git add .只处理当前目录及其子目录包含包含git add -A处理整个工作树包含包含git add -u只更新已跟踪文件不包含包含先说git add -A。它在仓库任意位置执行时都会扫描整个工作树把所有新增、修改、删除的变更都加入暂存区。如果你在仓库根目录执行git add .效果通常和 -A 一样但如果你当前在src/子目录里执行git add .它只会处理src/下面的变更仓库里其他目录的改动不会被动到。想从子目录一步到位处理全部变更用 -A 更稳妥。git add -u则只关注已经被 Git 跟踪的文件。它适合那种“我只想把已有文件的修改和删除纳入暂存但完全不想碰任何新文件”的场景。如果你新建了一堆临时文件但还没想好要不要提交用 -u 就不会误伤。选择依据很简单想要全部纳入就 -A只想处理当前目录就 .只想处理已跟踪文件就 -u。2.3 通配符与特殊文件名别让 shell 帮你吃掉匹配Git 的路径参数支持通配符但这块有个隐蔽的区别。直接执行git add *.txt时通配符通常先被 shell 展开成当前目录下所有 .txt 文件再传给 Git。也就是说匹配范围由 shell 决定基本就是当前目录这一层。而写成单引号形式git add *.txt通配符会保留给 Git 自己处理。Git 的 pathspec 匹配规则和 shell 不太一样它在匹配时不会把/当成天然边界所以*.txt会递归匹配当前目录下所有层级的 .txt 文件。这个特性很实用但也容易让人意外你可能只想添加当前目录的 txt结果子目录里的模板文件也被加入了。遇到这种情况用更明确的路径限定一下就好git add docs/*.txt另外通配符只能匹配到未被忽略的文件。如果某些文件命中 .gitignore 规则add 时会直接跳过。真想强制添加需要git add -f file这个 -f 选项相当于告诉 Git我知道这个文件在忽略规则里但我现在就是要把它加进去。正常场景下不推荐滥用。3. 进阶玩法用交互式暂存把提交拆得更干净3.1 git add -p只提交你想提交的那几行有经验的开发者会慢慢发现按文件粒度暂存还是太粗了。有时候一个文件里既有修复 bug 的代码又有临时调试输出你并不想把它们放进同一条提交。这时该用交互式暂存git add -p src/index.js-p是 patch 的意思它会让 Git 把文件改动拆成若干 hunk补丁块然后逐个询问你是否暂存。你可以按 y 暂存当前块按 n 跳过当前块按 q 退出。这样一来同一个文件的不同改动可以被拆进不同的提交历史记录会干净很多。比如你修了一个数据解析的 bug又顺手加了性能日志用git add -p就能只把修复 bug 的那几行加入暂存区日志代码留到下次提交。这类操作在 code review 时特别有优势审查者看到的每条提交都主题明确不需要从一堆无关改动里扒逻辑。3.2 交互命令速查y/n/d/s/e 到底代表什么用git add -p时Git 会逐个展示 hunk并等待你输入命令。最基本的几个命令完全可以背下来y暂存当前 hunkn不暂存当前 hunkq退出不再处理后续 hunka暂存当前 hunk并且把该文件剩余的所有 hunk 一起暂存d不暂存当前 hunk并且跳过该文件剩余的所有 hunks把当前 hunk 继续拆分成更小的 hunke手动编辑当前 hunks命令很适合处理那种一大段连续改动里混杂多种目的的情况。如果 Git 无法自动拆分或者拆分结果仍不满意就用 e 进入手动编辑模式。3.3 手动编辑 hunk 的注意事项手动编辑 hunk 是交互式暂存里门槛最高的部分因为你需要理解统一的 diff 格式。编辑界面展示的是一段补丁你需要把不希望暂存的行删掉保留希望暂存的行然后保存退出。这里有一个很容易翻车的细节补丁头部有类似 -10,6 10,8 的块计数信息。- 后面表示原始文件的起始行号和行数 后面表示新文件的起始行号和行数。你手动增加或删除了补丁内容后必须同步更新这个计数否则 Git 会认为补丁无法应用。比如你从补丁里删掉了新增的一行 后面的行数就要减一。对于大多数场景我建议尽量先用 s 拆分拆不到理想状态再手动编辑。手动编辑补丁是可行的但语法错误会直接导致本次暂存失败而且不会同步修改工作区文件操作前最好备份当前文件内容。练习几次之后你会发现这是让你提交历史真正“讲人话”的最强工具。4. 误把文件加入暂存区怎么撤销与补救4.1 撤销暂存但不删文件git restore --staged 与 git reset HEADadd 多了文件第一反应应该是撤销暂存而不是慌着删文件。Git 2.23 版本之后官方推荐的命令是git restore --staged file这条命令会把指定文件从暂存区状态恢复为 HEAD 版本对应的状态工作区里你改过的内容不会丢。也就是说git add之前是什么样执行后基本就回到什么样。如果想把当前所有已暂存的内容一次性撤销则执行git restore --staged .在老版本项目或旧习惯中你也会看到大量git reset HEAD file的写法。它的作用是类似的把暂存区中该路径的条目重置到 HEAD 位置。需要注意的是git reset如果不加路径执行的是git reset --mixed HEAD会把整个暂存区重置但不会改动工作区。这个行为对撤销全部暂存很有效但也因为 reset 这个词被很多人拿来滥用可能误伤其他暂存状态。我的建议是新项目里统一用git restore --staged语义清晰而且不会和更危险的 reset 历史操作混淆。只有你需要同时调整暂存区和某个提交引用范围时才去考虑 reset 家族。4.2 临时不跟踪但保留文件git rm --cached有些文件误加暂存区其实不是“暂存错了”而是“压根不该被 Git 跟踪”。比如配置文件、本地私有脚本、从没打算入库的目录。这时候光 restore --staged 还不够因为只要文件还在工作区下次 add 时它又会回来。正确做法是让它脱离 Git 跟踪但保留磁盘文件git rm --cached file--cached的含义就是只从索引里移除不物理删除文件。执行之后文件会处于一种“已从暂存区移除但保留在工作区”的状态接下来把它写进 .gitignore再正常提交一次它就不再参与后续跟踪。注意在已经 commit 过的历史里文件仍然存在于旧提交中。git rm --cached 只能阻止未来的提交继续包含它不能清除历史记录。如果文件里混入了敏感信息必须意识到旧提交依然残留这些内容需要更彻底的历史改写方案而不是简单删一下。4.3 敏感文件 / 不该提交的文件补救流程我在实际项目里处理过几次“日志文件被提交进仓库”的事故。补救流程基本固定先立刻撤销暂存并隔离文件git restore --staged logs/app.log git rm --cached logs/app.log echo logs/ .gitignore然后检查是否已经产生提交记录。如果还没 commit上面的操作足够干净如果已经 commit 甚至推送到了远端麻烦就大不少。本地可以改写历史但远端已经被其他人看到的内容很难真正撤回。这也是为什么我一再强调仓库根目录的 .gitignore 应该在项目初始化时就建好不要等出了事再补。顺带一提很多 IDE 会在保存时自动执行 git add或者在特定目录里生成临时文件。如果你发现暂存区经常出现自己没手动加过的文件先检查 IDE 是不是开启了自动暂存或格式化钩子这种间接原因最隐蔽。5. 实际项目里最容易踩的坑以及可复用的工作流5.1 CRLF 换行符为什么 add 后文件内容会突然变跨平台项目里一个经典现象是代码写着写着git status 突然显示整个文件都变了但你看编辑器里的内容和之前没啥区别。这种情况多半是换行符在捣乱。Windows 默认用 CRLF 换行Linux/macOS 用 LF。git add 在写入暂存区时会根据配置按需做换行符转换把工作区内容规整成仓库里约定好的格式。如果个人电脑的core.autocrlf设置和仓库约定不一致就会出现“明明没改几个字Git 却认为整个文件都变了”的错觉。这个坑的解法思路是仓库内统一约定个人端尽量跟随。常见做法是在仓库里放 .gitattributes 文件明确指定文本文件的换行规则比如* textauto eollf。你不需要记住所有转换细节但你至少要意识到git add 之前看到的内容和暂存区里记录的内容在换行符层面不一定逐字节一致这是设计行为不是 bug。判断文件是否真正改动可以用git diff --cached --stat结合具体区块查看。如果整个文件都是换行符变化那就是配置层面的问题不是代码改动。5.2 .gitignore 建得太晚已跟踪文件不受控很多人以为把文件写进 .gitignoreGit 就会自动忽略它。这个理解只对未跟踪文件成立。如果文件之前已经通过 add 或 commit 进入过版本管理.gitignore 对它无效你必须先执行 git rm --cached 让它退出跟踪。我见过一个场景某项目把整个 vendor 目录提交进了仓库后来想通过 .gitignore 忽略掉写了规则之后发现 git status 里 vendor 文件依然在列表里于是怀疑规则写错了。实际上规则没问题只是文件已经被跟踪忽略规则不会作用到已跟踪文件上。处理方式就是git rm -r --cached vendor执行后提交一次让仓库放弃对 vendor 的跟踪同时尽量保留本地文件。这之后 .gitignore 里的规则才真正生效。5.3 大仓库与批量添加add 之前先看 status在大型仓库里我见过有人习惯性执行git add -A结果把一个几 GB 的构建产物目录整个塞进暂存区。Git 虽然也能处理但后续每次 diff、每次提交都会变慢推送也会非常痛苦。比较稳的做法是养成先看状态、再决定添加范围的习惯git status --short输出里会清楚区分已修改、已删除、未跟踪文件。确认哪些该进暂存区后再选择精确路径或合适的 add 变体。尤其当 status 里出现你不认识的文件第一反应不应该是全量 add而是先搞清楚它从哪来。如果想拦一道可以在提交前执行git diff --cached --check这个命令会检查暂存区变更里是否存在空白错误比如行尾空格。它不能拦截所有问题但至少能在提交前多一道自动检查。5.4 一个我个人常用的提交前检查工作流我在实际开发里逐渐固定下来一套流程不算复杂但能避免大部分和暂存区相关的低级失误开发前确保工作区干净分支起点明确。改完代码先 git status看看有哪些新增和修改。按逻辑分组 add。同一个功能点相关的文件放一起临时生成的文件绝不 add。对单个文件改动较杂时用 git add -p 拆 hunk。add 完执行 git diff --cached认真看一遍即将提交的内容。确认无误再 commit。这套流程每步最多花几分钟但能长期保持提交记录整洁。所谓“会用 Git”很多时候不是会多少奇技淫巧而是愿意在提交前多看一眼暂存区里到底装了些什么。6. 常见问题速查表现象常见原因处理方式git add 后文件又显示 not stagedadd 之后再次修改了工作区文件重新 git add 该文件git add 报 pathspec 不匹配路径拼写错误、文件在忽略规则里git status 确认路径必要时 -f 强制添加提交里没有最新修改忘记重新 add先 git diff 对比工作区和暂存区内容文件写进 .gitignore 仍被跟踪文件已经被 Git 跟踪git rm --cached 后提交一次add 之后整个文件显示改动换行符、行尾差异检查 .gitattributes 与 core.autocrlf 配置一个文件改动想拆成多次提交未使用部分暂存用 git add -p 按 hunk 暂存误加了不该提交的大文件全量 add 时未过滤restore --staged、补充 .gitignore若已提交则需历史处理写在最后我使用 Git 这么多年最终体会到的一点是暂存区不是额外麻烦而是给你的一道缓冲。它允许你在把改动变成永久历史之前最后冷静地看一眼“我到底要提交什么”。尤其是git add -p这个功能第一次用会觉得麻烦用顺手之后你根本不想回到整文件提交的原始状态。现在每次提交之前我的习惯永远都是先 git status、再 git diff --cached这两步花不了多少时间却能让提交历史在几个月后依然一目了然。如果你刚开始接触 Git别急着背一堆高级命令。先把添加文件到暂存区这一步吃透弄清楚工作区和暂存区的关系后面所有撤销、回滚、分支合并的理解都会顺畅很多。 
长河君 · 2026/10/22 18:05:00 · 阅读 1.2k Git暂存区全解析：从git add到撤销，掌控提交历史的干净度
说实话很多人在使用 Git 一段时间后还是会不自觉地就把git add当成“保存文件”来理解。编辑器里按下 CtrlS内容落盘到工作区执行 git add很多人以为文件“已经提交到仓库了”其实这才刚走了一半。添加文件到暂存区是整个 Git 提交链条里最基础、也最容易被忽略的一步偏偏这步决定了你提交历史的干净程度。我见过太多提交记录里混着临时日志、编译产物和半成品代码根源基本都是暂存区没用好。如果你搞懂了暂存区是什么、add 到底做了什么、误加之后怎么补救你会发现 Git 的可控性比想象中高很多。这篇文章就把“添加文件到暂存区”这件事拆开聊从内部原理到日常命令再到多人协作里真正会踩的坑都过一遍。1. 先说清楚暂存区到底是一个什么样的存在1.1 工作区、暂存区、版本库三个区域各管各的Git 的日常操作其实是在三个区域之间搬东西工作区、暂存区、版本库。工作区就是你在磁盘上看到的文件目录你平时打开编辑器改的就是这里的内容暂存区是隐藏在 .git 目录里的一个状态记录区它不保存文件的完整副本而是保存“下一次提交准备记录哪些变更”版本库则存放了历史提交以及对应的完整文件快照。很多新手一开始只理解“改了文件、提交一下”这个流程把 git add 和 git commit 当成两个连续动作。实际上正是那个夹在中间的暂存区才让 Git 可以做到“一次提交只包含你希望包含的内容”。举个例子你一个下午改了三个功能点但不希望把它们揉进同一条提交记录这时候暂存区就是你的分拣台。你可以分三次 add 三个文件再分三次 commit得到三条清晰的提交记录。用生活一点的说法工作区是厨房台面菜都摆在那暂存区是备菜盘你决定哪几样先进锅版本库才是最终上桌的菜。git add 就是从台面上挑菜装进备菜盘的过程。1.2 git add 并不是“保存文件”而是登记变更要理解暂存区就要知道 git add 执行时内部发生了什么。很多人以为 add 会把文件复制进某个目录其实不是。当你执行git add README.md的时候Git 会做几件事先读取 README.md 的当前内容计算出一个哈希值把这个内容作为 blob 对象写进 .git/objects 目录然后更新暂存区索引文件 .git/index在这个索引里登记一条记录内容大致包括文件路径、文件权限模式、以及刚才算出来那个 blob 的哈希值。这个时候工作区里的 README.md 本身没有任何变化你也不会在 .git 里看到一个叫 README.md 的文件副本。真正被记录下来的是“这个文件在当前这一刻的内容是什么”的引用信息。索引文件相当于一份清单清单上写着下次提交时需要把哪些路径关联到哪些对象。这带来一个很关键的特性如果你在 add 之后又修改了工作区文件暂存区里记录的仍是上一次 add 时的内容不会自动跟着变。如果你不重新 add 就直接 commit提交里包含的就是旧版本而不是你最后一次保存的内容。这个坑几乎每个 Git 新手都会踩一次以后看到“Changes not staged for commit”的提示时第一反应应该是文件在工作区变了但暂存区还没有跟上。1.3 为什么 Git 非要搞一个暂存区有人可能会问既然最终都要提交为什么不直接 commit省掉 add 这一步这个问题背后其实是对 Git 设计哲学的理解提交是面向“逻辑单元”的而不是面向“时间点”的。没有暂存区的话所有工作区改动会一股脑进入下一次提交。那你可能一次提交里既修了 bug、又加了功能、还调整了格式将来回滚时根本不知道该回到哪个状态。暂存区允许你在提交前对变更做筛选和编排让每条提交都尽量保持单一职责。另外暂存区也为提交前检查提供了机会。你可以先 add 一部分文件然后通过git diff --cached仔细查看即将进入提交的内容确认没有遗漏、没有误加。这种“先审阅、再提交”的习惯在多人协作里尤其重要因为提交历史一旦推送出去改起来就麻烦得多。2. 最基础也最常用的 add 命令带你逐一过一遍2.1 精确添加什么时候用 git add 具体路径最朴素的做法就是指定文件路径git add README.md git add src/index.js src/utils/format.js git add docs/指定单个文件、多个文件或者整个目录Git 都支持。目录会被递归处理目录下所有未忽略的文件都会被加入暂存区。这种写法的好处是精确、可控适合你的改动本来就很零散、只需要提交其中一部分文件的时候。比如你同时改了接口文档和业务代码但想分两个提交就先 add 文档提交一次再 add 代码提交一次。有一点要注意路径里如果包含空格比如git add my file.txtshell 会把空格当成参数分隔符这时需要给整个文件名加引号git add my file.txt如果文件名本身以短横线开头比如-notes.txt直接写会被 Git 当成命令选项。提前用--分隔参数即可git add -- -notes.txt这种边界情况平时不常见但遇到了很容易卡住记下来能省不少时间。2.2 git add .、-A、-u三个兄弟到底怎么选日常讨论度最高的三个形式是git add .、git add -A和git add -u。它们不是完全等价很多分歧都来自这里。命令作用范围是否包含新建文件是否包含删除文件git add .只处理当前目录及其子目录包含包含git add -A处理整个工作树包含包含git add -u只更新已跟踪文件不包含包含先说git add -A。它在仓库任意位置执行时都会扫描整个工作树把所有新增、修改、删除的变更都加入暂存区。如果你在仓库根目录执行git add .效果通常和 -A 一样但如果你当前在src/子目录里执行git add .它只会处理src/下面的变更仓库里其他目录的改动不会被动到。想从子目录一步到位处理全部变更用 -A 更稳妥。git add -u则只关注已经被 Git 跟踪的文件。它适合那种“我只想把已有文件的修改和删除纳入暂存但完全不想碰任何新文件”的场景。如果你新建了一堆临时文件但还没想好要不要提交用 -u 就不会误伤。选择依据很简单想要全部纳入就 -A只想处理当前目录就 .只想处理已跟踪文件就 -u。2.3 通配符与特殊文件名别让 shell 帮你吃掉匹配Git 的路径参数支持通配符但这块有个隐蔽的区别。直接执行git add *.txt时通配符通常先被 shell 展开成当前目录下所有 .txt 文件再传给 Git。也就是说匹配范围由 shell 决定基本就是当前目录这一层。而写成单引号形式git add *.txt通配符会保留给 Git 自己处理。Git 的 pathspec 匹配规则和 shell 不太一样它在匹配时不会把/当成天然边界所以*.txt会递归匹配当前目录下所有层级的 .txt 文件。这个特性很实用但也容易让人意外你可能只想添加当前目录的 txt结果子目录里的模板文件也被加入了。遇到这种情况用更明确的路径限定一下就好git add docs/*.txt另外通配符只能匹配到未被忽略的文件。如果某些文件命中 .gitignore 规则add 时会直接跳过。真想强制添加需要git add -f file这个 -f 选项相当于告诉 Git我知道这个文件在忽略规则里但我现在就是要把它加进去。正常场景下不推荐滥用。3. 进阶玩法用交互式暂存把提交拆得更干净3.1 git add -p只提交你想提交的那几行有经验的开发者会慢慢发现按文件粒度暂存还是太粗了。有时候一个文件里既有修复 bug 的代码又有临时调试输出你并不想把它们放进同一条提交。这时该用交互式暂存git add -p src/index.js-p是 patch 的意思它会让 Git 把文件改动拆成若干 hunk补丁块然后逐个询问你是否暂存。你可以按 y 暂存当前块按 n 跳过当前块按 q 退出。这样一来同一个文件的不同改动可以被拆进不同的提交历史记录会干净很多。比如你修了一个数据解析的 bug又顺手加了性能日志用git add -p就能只把修复 bug 的那几行加入暂存区日志代码留到下次提交。这类操作在 code review 时特别有优势审查者看到的每条提交都主题明确不需要从一堆无关改动里扒逻辑。3.2 交互命令速查y/n/d/s/e 到底代表什么用git add -p时Git 会逐个展示 hunk并等待你输入命令。最基本的几个命令完全可以背下来y暂存当前 hunkn不暂存当前 hunkq退出不再处理后续 hunka暂存当前 hunk并且把该文件剩余的所有 hunk 一起暂存d不暂存当前 hunk并且跳过该文件剩余的所有 hunks把当前 hunk 继续拆分成更小的 hunke手动编辑当前 hunks命令很适合处理那种一大段连续改动里混杂多种目的的情况。如果 Git 无法自动拆分或者拆分结果仍不满意就用 e 进入手动编辑模式。3.3 手动编辑 hunk 的注意事项手动编辑 hunk 是交互式暂存里门槛最高的部分因为你需要理解统一的 diff 格式。编辑界面展示的是一段补丁你需要把不希望暂存的行删掉保留希望暂存的行然后保存退出。这里有一个很容易翻车的细节补丁头部有类似 -10,6 10,8 的块计数信息。- 后面表示原始文件的起始行号和行数 后面表示新文件的起始行号和行数。你手动增加或删除了补丁内容后必须同步更新这个计数否则 Git 会认为补丁无法应用。比如你从补丁里删掉了新增的一行 后面的行数就要减一。对于大多数场景我建议尽量先用 s 拆分拆不到理想状态再手动编辑。手动编辑补丁是可行的但语法错误会直接导致本次暂存失败而且不会同步修改工作区文件操作前最好备份当前文件内容。练习几次之后你会发现这是让你提交历史真正“讲人话”的最强工具。4. 误把文件加入暂存区怎么撤销与补救4.1 撤销暂存但不删文件git restore --staged 与 git reset HEADadd 多了文件第一反应应该是撤销暂存而不是慌着删文件。Git 2.23 版本之后官方推荐的命令是git restore --staged file这条命令会把指定文件从暂存区状态恢复为 HEAD 版本对应的状态工作区里你改过的内容不会丢。也就是说git add之前是什么样执行后基本就回到什么样。如果想把当前所有已暂存的内容一次性撤销则执行git restore --staged .在老版本项目或旧习惯中你也会看到大量git reset HEAD file的写法。它的作用是类似的把暂存区中该路径的条目重置到 HEAD 位置。需要注意的是git reset如果不加路径执行的是git reset --mixed HEAD会把整个暂存区重置但不会改动工作区。这个行为对撤销全部暂存很有效但也因为 reset 这个词被很多人拿来滥用可能误伤其他暂存状态。我的建议是新项目里统一用git restore --staged语义清晰而且不会和更危险的 reset 历史操作混淆。只有你需要同时调整暂存区和某个提交引用范围时才去考虑 reset 家族。4.2 临时不跟踪但保留文件git rm --cached有些文件误加暂存区其实不是“暂存错了”而是“压根不该被 Git 跟踪”。比如配置文件、本地私有脚本、从没打算入库的目录。这时候光 restore --staged 还不够因为只要文件还在工作区下次 add 时它又会回来。正确做法是让它脱离 Git 跟踪但保留磁盘文件git rm --cached file--cached的含义就是只从索引里移除不物理删除文件。执行之后文件会处于一种“已从暂存区移除但保留在工作区”的状态接下来把它写进 .gitignore再正常提交一次它就不再参与后续跟踪。注意在已经 commit 过的历史里文件仍然存在于旧提交中。git rm --cached 只能阻止未来的提交继续包含它不能清除历史记录。如果文件里混入了敏感信息必须意识到旧提交依然残留这些内容需要更彻底的历史改写方案而不是简单删一下。4.3 敏感文件 / 不该提交的文件补救流程我在实际项目里处理过几次“日志文件被提交进仓库”的事故。补救流程基本固定先立刻撤销暂存并隔离文件git restore --staged logs/app.log git rm --cached logs/app.log echo logs/ .gitignore然后检查是否已经产生提交记录。如果还没 commit上面的操作足够干净如果已经 commit 甚至推送到了远端麻烦就大不少。本地可以改写历史但远端已经被其他人看到的内容很难真正撤回。这也是为什么我一再强调仓库根目录的 .gitignore 应该在项目初始化时就建好不要等出了事再补。顺带一提很多 IDE 会在保存时自动执行 git add或者在特定目录里生成临时文件。如果你发现暂存区经常出现自己没手动加过的文件先检查 IDE 是不是开启了自动暂存或格式化钩子这种间接原因最隐蔽。5. 实际项目里最容易踩的坑以及可复用的工作流5.1 CRLF 换行符为什么 add 后文件内容会突然变跨平台项目里一个经典现象是代码写着写着git status 突然显示整个文件都变了但你看编辑器里的内容和之前没啥区别。这种情况多半是换行符在捣乱。Windows 默认用 CRLF 换行Linux/macOS 用 LF。git add 在写入暂存区时会根据配置按需做换行符转换把工作区内容规整成仓库里约定好的格式。如果个人电脑的core.autocrlf设置和仓库约定不一致就会出现“明明没改几个字Git 却认为整个文件都变了”的错觉。这个坑的解法思路是仓库内统一约定个人端尽量跟随。常见做法是在仓库里放 .gitattributes 文件明确指定文本文件的换行规则比如* textauto eollf。你不需要记住所有转换细节但你至少要意识到git add 之前看到的内容和暂存区里记录的内容在换行符层面不一定逐字节一致这是设计行为不是 bug。判断文件是否真正改动可以用git diff --cached --stat结合具体区块查看。如果整个文件都是换行符变化那就是配置层面的问题不是代码改动。5.2 .gitignore 建得太晚已跟踪文件不受控很多人以为把文件写进 .gitignoreGit 就会自动忽略它。这个理解只对未跟踪文件成立。如果文件之前已经通过 add 或 commit 进入过版本管理.gitignore 对它无效你必须先执行 git rm --cached 让它退出跟踪。我见过一个场景某项目把整个 vendor 目录提交进了仓库后来想通过 .gitignore 忽略掉写了规则之后发现 git status 里 vendor 文件依然在列表里于是怀疑规则写错了。实际上规则没问题只是文件已经被跟踪忽略规则不会作用到已跟踪文件上。处理方式就是git rm -r --cached vendor执行后提交一次让仓库放弃对 vendor 的跟踪同时尽量保留本地文件。这之后 .gitignore 里的规则才真正生效。5.3 大仓库与批量添加add 之前先看 status在大型仓库里我见过有人习惯性执行git add -A结果把一个几 GB 的构建产物目录整个塞进暂存区。Git 虽然也能处理但后续每次 diff、每次提交都会变慢推送也会非常痛苦。比较稳的做法是养成先看状态、再决定添加范围的习惯git status --short输出里会清楚区分已修改、已删除、未跟踪文件。确认哪些该进暂存区后再选择精确路径或合适的 add 变体。尤其当 status 里出现你不认识的文件第一反应不应该是全量 add而是先搞清楚它从哪来。如果想拦一道可以在提交前执行git diff --cached --check这个命令会检查暂存区变更里是否存在空白错误比如行尾空格。它不能拦截所有问题但至少能在提交前多一道自动检查。5.4 一个我个人常用的提交前检查工作流我在实际开发里逐渐固定下来一套流程不算复杂但能避免大部分和暂存区相关的低级失误开发前确保工作区干净分支起点明确。改完代码先 git status看看有哪些新增和修改。按逻辑分组 add。同一个功能点相关的文件放一起临时生成的文件绝不 add。对单个文件改动较杂时用 git add -p 拆 hunk。add 完执行 git diff --cached认真看一遍即将提交的内容。确认无误再 commit。这套流程每步最多花几分钟但能长期保持提交记录整洁。所谓“会用 Git”很多时候不是会多少奇技淫巧而是愿意在提交前多看一眼暂存区里到底装了些什么。6. 常见问题速查表现象常见原因处理方式git add 后文件又显示 not stagedadd 之后再次修改了工作区文件重新 git add 该文件git add 报 pathspec 不匹配路径拼写错误、文件在忽略规则里git status 确认路径必要时 -f 强制添加提交里没有最新修改忘记重新 add先 git diff 对比工作区和暂存区内容文件写进 .gitignore 仍被跟踪文件已经被 Git 跟踪git rm --cached 后提交一次add 之后整个文件显示改动换行符、行尾差异检查 .gitattributes 与 core.autocrlf 配置一个文件改动想拆成多次提交未使用部分暂存用 git add -p 按 hunk 暂存误加了不该提交的大文件全量 add 时未过滤restore --staged、补充 .gitignore若已提交则需历史处理写在最后我使用 Git 这么多年最终体会到的一点是暂存区不是额外麻烦而是给你的一道缓冲。它允许你在把改动变成永久历史之前最后冷静地看一眼“我到底要提交什么”。尤其是git add -p这个功能第一次用会觉得麻烦用顺手之后你根本不想回到整文件提交的原始状态。现在每次提交之前我的习惯永远都是先 git status、再 git diff --cached这两步花不了多少时间却能让提交历史在几个月后依然一目了然。如果你刚开始接触 Git别急着背一堆高级命令。先把添加文件到暂存区这一步吃透弄清楚工作区和暂存区的关系后面所有撤销、回滚、分支合并的理解都会顺畅很多。