桃子胖1. 为什么会用到stash：工作区被打断的真实场景
先说一个我自己的真实经历。有次我在一个功能分支上改了差不多半天的代码，涉及六个文件，其中三个改动了一半还没编译通过。就在这个节骨眼上，线上环境出了个紧急问题，需要立刻切到主分支去修一个hotfix。当时我脑子里第一反应是：完蛋了，这半天的改动怎么办。
直接commit？代码是坏的，编译都过不了，提交上去就是污染历史。直接切分支？Git根本不会让你切，工作区和暂存区有未提交的改动，它会拦住你说“本地改动会被覆盖”。
那时候我刚用Git不久，对stash只停留在“听说过”的层面，差点就手动把改动文件一份份备份到桌面上，然后硬切分支。后来用了git stash，整个人都轻松了。一条命令，所有未提交的改动全部收起来，工作区干净得像是刚刚clone下来的仓库，你可以放心大胆地切分支、做hotfix、再切回来，然后一条命令恢复现场。
所以这篇东西我不打算写成枯燥的命令手册，而是想把这两年stash用在各种场景下的经验，包括怎么用、什么时候用、踩过哪些坑，完整地捋一遍。尤其是git stash配合分支切换、代码审查、多任务并行这些情况，用好了真的能省掉非常多心烦意乱的操作。
先明确一下stash解决的核心问题：它让你可以临时把工作区的“半成品”保存到一个独立的区域，让工作区恢复干净，同时又不需要提交任何不完整的代码。 换句话说，它解决的是“还没做完、暂时又做不下去”的保存问题。跟你把书本合上、夹个书签放在书架上是同一个道理，不是把这一页撕下来扔掉，也不是硬着头皮把半本书读完。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. stash基础操作全解：保存、查看、恢复、清除
2.1 stash保存的完整姿势，不只git stash一种
最基础最常用的就是直接执行git stash。不带任何参数时，它默认会把所有已跟踪文件的修改（包括已暂存和未暂存的改动）保存到stash栈中，然后工作区回到HEAD状态。注意这里有个关键点：默认情况下，它不会保存untracked文件。
什么叫untracked文件？就是那些你新建了但从来没有git add过的文件。很多人在这里吃过亏：新建了一个配置文件，改了半天，执行git stash，结果切完分支回来发现新文件还在，根本就没被stash存走。
这个设计其实是有意为之的。git stash默认逻辑是“把我正在修改的、已经在版本控制里的内容收起来”，而新建的、还没纳入版本控制的文件，Git认为它们不属于“正在做的修改”的一部分，可能只是临时测试用的东西。但实际工作中，新文件往往就是我们改动的一部分，所以更完整的保存命令应该这样用：
bash复制# 保存所有已跟踪文件的改动
git stash
# 保存所有改动，包含新建但未跟踪的文件
git stash -u
# 保存所有改动，包含未跟踪文件，同时包含被忽略的文件
git stash -a
这三个命令的区分特别重要。-u是--include-untracked，-a是--all。我自己最常用的就是git stash -u。因为我的习惯是开发时经常加一些临时的新文件来做调试，这些文件虽然是新的，但确实是我的工作成果，如果默认的git stash存不走它们，回头恢复的时候会发现工作区一半是恢复好的修改，一半还留着没动的新文件，很容易漏东西。
还有一个不太为人知但很实用的选项是git stash --keep-index。它的作用是：把工作区的改动存入stash，但保留暂存区的状态不变。我们经常会遇到这种场景：你已经把一部分改动用git add暂存了，形成了几个逻辑清晰的文件组，然后工作区还有另外一些改动不想现在处理。此时用--keep-index，stash会存走工作区的改动，但被暂存的内容不会动。
举个例子，我改了A、B、C三个文件，只有A是准备本次提交的内容，B和C是另一件事的改动。我执行git add A，再执行git stash --keep-index，结果就是B和C被存走，A仍然在暂存区，工作区里A的改动也依然保留。然后我可以临时基于A的内容做其他操作，回头再恢复B和C继续写。这个命令用得好，会让你对“暂存区”和“工作区”的理解上一个台阶。
2.2 查看与恢复：stash list、stash pop、stash apply
存好之后，怎么确认存了哪些东西？用git stash list，输出大概长这样：
code复制stash@{0}: WIP on feature/login: 3a4f6x2 完善登录接口参数校验
stash@{1}: WIP on master: dcnf9a1 修复首页白屏问题
stash@{2}: On feature/user: 原来不太规范的描述
每一条都是一个stash记录，最上面的是最近保存的。stash@{0}、stash@{1}这种编号就是每条记录的索引。默认查看具体某条stash改了什么内容，用git stash show：
bash复制# 默认显示最近一条stash的文件变更统计
git stash show
# 显示完整diff
git stash show -p stash@{0}
# 显示统计信息
git stash show --stat stash@{1}
恢复的时候有两个容易混淆的命令：git stash pop和git stash apply。pop是“应用并删除”，也就是说恢复这条stash之后，它会从stash列表里移除；apply是“应用但保留”，恢复之后stash记录还在，可以多次应用。
这个区别决定了两个命令的使用场景完全不同。最常用的git stash pop适合那种“我临时存一下，现在回来继续干活”的情况，一条命令恢复现场，干净利落。而git stash apply适合“我需要把某次stash的内容同步到多个分支”的情况，比如你在一分支上改了个通用的修复，stash起来之后切到多个分支去应用，每次都保留stash记录，等所有分支都处理完再统一git stash drop清理。
2.3 精确控制：恢复指定某条stash
如果只有一条stash，直接git stash pop就够了，但如果你同时开了多个任务，stack里面有五六条stash记录，那每次pop都是弹出栈顶的那条，很容易弹错。这时候需要指定编号来恢复：
bash复制git stash pop stash@{2}
注意这里的语法细节：如果你在pop后面直接写stash@{2}，有些老版本Git会提示你需要加--index或完整写法，但现代版本基本都支持直接指定。执行后stash@{2}会被恢复并从列表移除，原来它上面的那些stash索引会自动重新排列。
另一个容易忽略的是git stash pop --index。我们分两种情况来看：
- 不带
--index：stash里的所有改动恢复成工作区的未暂存状态。 - 带
--index：如果当时stash之前，某些文件是已经git add暂存的，恢复后也会尽量恢复暂存状态。
用一句话说就是：--index会尽力还原你stash那一刻的“暂存区结构”。我的建议是，如果保存stash之前你做了暂存，恢复时加上--index能减少很多后续重新git add的麻烦。代价是偶尔会因为版本不一致导致恢复过程报错，后面第4章会详细讲冲突处理。
2.4 清理与维护：drop、clear
stash存多了不清理，stack就会越来越乱。基础的清理就三条命令：
bash复制# 删除指定的某条stash
git stash drop stash@{2}
# 清空所有stash
git stash clear
# 删除最近一条
git stash drop
drop和clear都是不可逆操作，删了就没有了。如果说git stash pop是“取走”，那drop就是“扔掉”。我见过不少同事执行git stash clear之后发现其中有一条stash是几个小时的工时，瞬间整个人就不好了。所以这里必须再强调一遍：没有所谓的recover机制，clear之后就真没了，除非你当时把stash的diff导出过文件或者使用了一些第三方的reflog恢复工具，否则基本等于白干。
实操上我建议养成一个习惯：stash记录不要长期堆积，当天的stash当天恢复处理，超过三天没用的stash，多半已经不需要了，该drop就drop。stack里最多留三到五条，再多就真的分不清哪条对应哪个任务了。
3. stash的进阶玩法：挑文件、挑记录、救急冲突
基础命令用熟了之后，你可能会遇到更多具体问题。比如我只想存某个文件，不想全部存走；再比如我stash里面有一条已经不需要了，但pop出来恢复的时候冲突了。这些问题都有对应的处理技巧。
3.1 只stash部分文件
默认git stash是存所有已跟踪文件的改动，但如果一个分支上同时改了多个文件，而我只想存其中一个文件的修改，怎么办？Git直接提供一个路径参数：
bash复制git stash push -m "只保存配置文件改动" -- src/config.js
注意--后面的路径是用来限定范围的，不写-m也可以，但建议每次都加-m描述，否则git stash list里看到的就是一条条毫无区分的“WIP on branch”，时间一长你根本记不起哪条是哪条。我这里特别说一下命名的重要性：git stash push -m "描述"是给stash增加可读性最有效的方式。比如你存了一个登录模块的改动，就写-m "登录页联调未完成"，下次看list就知道这条stash是什么内容。
可以一次指定多个文件：
bash复制git stash push -m "样式和接口文件" -- src/styles.scss src/api.js
这个用法在“同一分支上同时进行两个不相关的修改”时特别有优势。比如我经常遇到：正在改A需求时，突然收到一个紧急的小优化，但这个优化和A需求完全不搭边。我可以先只stash掉A需求涉及的文件，然后专门改小优化、提交、推送，再pop回来继续写A。
3.2 从stash创建独立分支，省掉来回切换
stash一个非常高级的用法是：git stash branch。有时候你存了一条stash，但恢复的时候发现当前分支跟你保存stash时的分支状态已经差得很远了，硬pop必然产生大量冲突。这种场景下，正确的做法是专门为这条stash开一个分支：
bash复制git stash branch fix-login-bug stash@{1}
这条命令做的事情有三步：
- 基于保存stash时的那个提交，创建并切换到一个新分支
fix-login-bug； - 把对应stash的改动应用到这个分支上；
- 应用成功后直接drop掉这条stash记录。
这个命令的好处在于它最大程度上避免了“恢复stash到错误分支”带来的冲突。如果你当时stash时工作区是基于旧的提交，而你现在所在的分支已经从那个提交点往前走了很多，直接pop的话可能几十个文件的冲突等着你；而git stash branch会回到那个旧的提交点，应用你的改动，让你在一个“跟保存时状态一致”的环境里继续干活。这在处理跨分支修复bug时真的是救命级别的操作。
3.3 一次stash，多分支重复利用
另一种场景是想把同一个stash的内容同步到多个分支。比如你修复了一个公共逻辑，这个修复改动只有一处，但需要切到feature-A、feature-B、feature-C分别提交一次。这个时候用pop肯定不行，因为pop用一次就没了。正确做法是用apply：
bash复制git checkout feature-A
git stash apply stash@{0}
git add public.js
git commit -m "修复公共逻辑"
git checkout feature-B
git stash apply stash@{0}
git add public.js
git commit -m "修复公共逻辑"
这样stash@{0}会一直被保留，直到所有分支都处理完了，你手动执行git stash drop清理掉。用这个方法还可以顺便保持多次提交的内容一致，不会出现分支间修复细节不一致的问题。
3.4 stash的存储细节到底存在哪
这里稍微深入一点讲讲原理。stash并不是什么神秘的独立存储，它的底层实现实际上就是创建了若干个特殊的提交对象。当你执行git stash时，Git会基于当前HEAD创建一个“未提交的提交”，保存你当时的索引状态和工作区状态。这个提交用普通的git log是看不到的，但在git log --all和引用日志中是可以追踪到的。
这也是为什么很多Git图形化工具（比如SourceTree、Fork）都会在界面上单独列出一个“Stashes”区域。了解这一点有什么实际价值？价值在于：当你误删了stash记录时，理论上可以通过Git的reflog和对象库去翻找那些孤立的提交对象。虽然操作门槛不低，但至少你知道了stash的数据不是凭空消失，而是变成了一堆Lost and Found里的孤儿提交。极端情况下还能抢救一下，这个后面第4章详细讲。
3.5 stash与untracked文件、忽略文件的边界处理
刚才提到git stash默认不保存untracked文件。那如果我要保存untracked文件，用-u，如果连.gitignore忽略的文件也要保存，用-a。这里要特别提醒一个坑：-a可能会把你本地的环境配置、密钥文件、日志文件等不该提交的内容也一并存进stash。比如你本地有一个.env.local文件，里面写了开发环境的数据库连接串，正常它应该被.gitignore忽略。如果你执行了git stash -a，这个文件就会被带进stash里。要是你后面不小心把stash的内容apply到别的机器或别的分支上，开发环境的敏感信息就可能出现在不该出现的位置。
所以我的经验是：默认能用git stash -u就不用-a，除非你完全清楚自己仓库里有哪些被忽略文件，并且确认它们出现在stash里没有任何副作用。 至于这两种方式是否会影响恢复时的表现，实际上在恢复时它们都会以文件形式出现在工作区，区别只在于保存时是否被纳入范围。
4. 踩坑记录：stash丢失、冲突与误清空的处理经验
说了这么多用法，接下来分享几个我实际碰到的坑。这些坑在我一开始用stash的头一两年里几乎都踩过一遍，写出来给大家排排雷。
4.1 stash pop出现冲突，别慌，先看提示
先说一个最常见的：git stash pop之后提示冲突。场景往往是这样的——stash的时候你的工作区是基于某个提交点的，之后你又在这个分支上做了其他提交，这几个提交改动的文件和stash里存的文件有重叠区域，于是pop的时候Git没法干净地合并，就会提示冲突。
很多人一看冲突就懵了，第一反应是：stash会不会没存好？我的改动哪里去了？其实不用慌，这种冲突跟普通的merge冲突处理起来一模一样。Git会把你stash里的改动和你当前工作区的改动都标记在文件里，你需要手动编辑保留正确的部分，然后像普通解决冲突一样：
bash复制git add 冲突文件
git commit -m "恢复stash内容并解决冲突"
不过这里有一个细节要特别注意：pop冲突时，Git不会自动drop这条stash记录。即使你解决了冲突并提交了，git stash list里那条stash还在。因为Git无法确认你的冲突是否真正解决完毕，所以它选择“保守地保留原记录”。如果你确定已经处理好所有冲突了，需要手动git stash drop去清理这条记录。
这个机制本身是安全的设计，但很多人不懂就以为stash已经应用过了，结果第二天又执行一次pop，发现又弹出一堆旧改动，整个人瞬间头大。所以我给大家一个口诀：pop冲突之后，永远记得检查git stash list，处理完冲突后手动drop掉已经无用那条。
4.2 恢复时的常见冲突类型与解决技巧
stash冲突本质上有三种来源：
第一种是stash保存后，分支上又有了新的提交，且新提交修改的文件与stash重叠。这种最常见，解决思路就是手动合并，把两边的改动都保留下来。
第二种是stash保存后，你切换了分支，恢复到了错误的分支上。比如stash是在feature分支存的，你用git stash pop在master上恢复，结果master的代码跟feature差异巨大，冲突铺天盖地。这种情况我强烈建议直接取消恢复操作，不要硬解：
bash复制# 取消当前pop产生的冲突合并状态
git merge --abort
# 或者如果你已经手动编辑到一半：
git reset --hard HEAD
但注意git reset --hard HEAD会把所有未提交的改动全部清掉，包括你刚才手动编辑的一部分结果。所以最好是在公共编辑器自动合并后的初始状态下就发现冲突规模超出预期，果断放弃重来，改用前面讲的git stash branch回到原本所属的分支去恢复。
第三种是stash内部的暂存区状态与当前Git版本行为不一致导致的冲突。这种情况在git stash pop --index时偶尔会遇到。Git在恢复时会尝试重建你当时的索引结构，但如果目标分支的HEAD已经变了，索引重建就可能失败。通常提示是“Cannot apply stash: Your index contains uncommitted changes”，解决办法就是去掉--index，改用普通的git stash pop，恢复后再手动git add。
4.3 误清空stash之后，还有没有救
虽然我在前面说git stash clear之后基本等于白干，但严谨地说，还是有两个可能的抢救路径。第一个是看看有没有其他机器或者同事的仓库里有相同的历史，如果同一仓库在其他地方有clone，对方那边的stash记录可能还在，直接把那个存储目录对象的引用复制过来即可。
第二个路径是利用reflog。虽然stash记录本身被删除了，但它对应的提交对象在Git对象库里可能还残存一段时间。你可以用git fsck --lost-found去扫描仓库里的dangling commit，理论上能找到那些还在对象库里等待被垃圾回收的stash提交。但这些提交的message通常都明确带着“WIP on branch”字样，能帮你识别出来。操作过程大致是：
bash复制# 扫描孤立提交对象
git fsck --lost-found
# 找到可疑的commit后，查看内容确认
git show <commit-id>
# 确认无误后，把内容取出来
git cherry-pick <commit-id>
# 或者基于该commit创建分支
git branch recover-stash <commit-id>
多说一句，这套方法真的指望上的概率不高，因为Git的自动gc会在一定时间后清理这些孤立对象。但它给了我们最后一个“后悔药”的入口，有总比没有好。日常更重要的还是养成良好习惯，不要动不动就clear。
4.4 误编辑或误丢失stash的极端救援技巧
除了误清除，还有一种场景：你正在解决stash冲突的中间状态，不小心执行了git checkout .或者git reset --hard，把应用出来但还没处理的内容弄没了。这时候同样回到对象库去找。因为stash对应的提交对象在你执行pop时并不会立刻消失，它直到对应stash引用被删除前都存在着。
你可以先检查git stash list，如果那条记录还在，那就好办，重新git stash apply一次即可。如果那条记录已经不在list里了，就用git fsck --lost-found扫描。我做过一次成功恢复，记忆很深，当时满屏的dangling commit里翻了半天，最后看到一条message是“On feature/payment: 支付回调处理未完成”，心里那块石头才落了地。
4.5 多分支并行开发时的stash管理策略
当你在几个分支之间反复横跳时，stash的栈结构就特别容易搞混。我现在养成的习惯是给每条stash起一个非常明确的名字，格式是：任务名-日期-状态。比如：
bash复制git stash push -m "购物车样式-0425-联调中" -u
git stash push -m "订单列表分页-0425-需补接口" -u
这样每次git stash list一眼就能看清当前有几个任务、每个任务进行到哪一步。另外我还会避免一次stash存好几件事的改动，尽量用git stash push --限定单文件范围，把不同任务的修改隔离到不同的stash里。虽然操作上会多一些命令，但这些辛苦是为了防止后面恢复时串场。
如果分支数量确实很多，我甚至建议直接放弃stash而改用“临时分支 + WIP commit”的方式。做法就是把当前改动提交到一个wip/xxx分支上：
bash复制git switch -c wip/login-page
git add -A
git commit -m "WIP: 登录页联调中，代码未完成"
git switch master
等主分支的hotfix处理完，再切回wip分支git reset --soft HEAD~1把提交退回到暂存区，继续干活。这种方式有两个好处：一是WIP分支可以push到远程，多台机器之间同步非常方便；二是提交历史里有明确的记录，不会像stash那样堆积在栈里越积越深。代价是你会多留下一条“丑陋”的commit，但如果你始终在wip分支上不断修改并amend提交，最终合并时再把多个commit压缩成一个，历史照样是干净的。
4.6 stash和git worktree结合，效率再上一层
最后再提一个我实际用下来很舒服的组合方式：git stash配合git worktree。worktree允许你在同一个仓库上同时检出多个分支到不同的目录，互不干扰。用它来配合stash，可以做到真正的“分支间同时开工”。
比如我在主目录~/project是feature-A的开发环境，同时在~/project-hotfix检出了master分支处理线上问题。这样我完全不需要存stash再切分支——两边目录是独立的工作区。但为什么还要用stash？因为有时候两边都需要同一个未完成的中间状态，或者我需要带着某份改动在分支间迁移，这时候worktree并不能直接共享未提交的改动，stash就成了“搬运”修改的桥梁：在A worktree里git stash push -u，到B worktree里git stash apply，一气呵成。
这种方式比传统“一个目录反复切换+stash”要舒服得多，尤其适合那些经常需要同时维护“新功能开发”和“线上bug修复”两条线的同学。
5. 实操心得：把stash用成肌肉记忆
我刚开始用Git的头半年，基本是“commit为主，stash不敢碰”的状态。总觉得stash是把东西放进了某个看不见的地方，有点虚，怕放进去就找不出来了。后来被紧急hotfix逼着用了几次，才慢慢上手。现在我几乎每天都会用stash，而且坦白讲，用得越多越觉得它更像一个“任务切换器”。
真正让我从“会用”转变到“用得好”的，是一次连续多天的多需求并行开发。当时我在同一分支上同时推进三个子功能，每天早上第一件事就是先看git stash list，确认昨天存到哪一步了。三条stash分别命名清晰，恢复时各归各位。那几天的节奏就是：写代码、存stash、切分支处理另一个任务、再切回来、恢复stash、继续写。整个过程非常顺滑，几乎没有任何心智负担。
后来我把这套流程也带到了团队里，给同事分享的重点就三条：命名要让人看得懂、恢复动作要确认当前分支状态、stash栈要定期清理。别小看这三条，真的做到位，stash这个命令在你手里就从“偶尔用的工具”变成了“高频使用的核心工作流”。
如果在使用stash的过程中遇到任何问题，其实最有效的排错思路是回到它的本质：stash就是一组提交对象，它保存的是你在某一时刻的工作区与暂存区快照。任何冲突、丢失、混乱，只要抓住这个本质去思考，基本都能找到出路。
写到这里，我的stash使用经验差不多都掏干净了。最后再用一句话总结本质：stash不解决“代码怎么写”的问题，但它能解决“代码写了一半被打断”的问题。 把这条命令练成肌肉记忆，你会在无数个手忙脚乱的场景里感谢自己当初花时间搞懂了它。