"git stash"这个词，用过的都说香，但真正玩明白的人真不多。工作区改到一半，突然要切分支、改bug、拉代码，手头这堆改动的去留就成了最闹心的事。本篇文章就从底层逻辑到实操细节，把git stash的用法彻底掰开揉碎，尤其是stash pop的冲突解决，我直接把我踩过的坑和排查思路全给出来，你看完就能直接用。
1. 为什么需要git stash：从日常开发场景说起
1.1 工作中最常见的"切换中断"场景
先问你一个场景：你正在自己的分支上加一个新功能，改了差不多三四个文件，里头包括一个公共配置文件的改动。突然测试那边抛了个线上bug，优先级拉到最高，你必须在五分钟内切到主分支，拉个hotfix分支，赶紧修复上线。
这时候你怎么办？直接git checkout master，Git会警告你："本地改动会被覆盖"。因为你改了文件，Git不允许直接切换分支。很多人这时候就开始复制粘贴备份文件，或者干脆git add + git commit，留下一条"临时提交（别打我看不懂）"这种历史记录，丑得不行。
stash就是干这个的。它把你的工作区改动"暂存起来"，使工作区恢复到一个干净的HEAD状态。你该切分支切分支，该拉代码拉代码。等hotfix处理完了，再切回来，执行git stash pop，改动原封不动地回来了，仿佛这段时间什么都没发生。
这个操作的本质，其实是Git提供了一个独立于工作区、索引区和提交历史的"暂存储物间"。你在里面放多少东西都行，只要记得取出来就好。
1.2 stash到底帮你保住了什么
Git的改动其实分两种：已跟踪文件的修改，和未跟踪的新文件。默认情况下，git stash只暂存前者。也就是说，你新建的文件（untracked files），如果不特别说明，stash不会管它。这是个特别容易踩的坑。很多人改了代码、新建了一个文件，调了半天，切完分支再切回来，发现代码全回来了，就新建的那个文件不见了。其实它一直都躺在工作区里，只是stash没带上它而已。后面我会专门讲-u参数。
所以，stash的现实意义在于：它让你的开发状态可以"整个挂起"，而不是被迫中断或留下不洁的历史。这种状态管理能力，在频繁切换上下文的开发文化里，可以说是必备技能。
1.3 适用人群与场景清单
如果你属于以下几类开发者，我建议你花十分钟把这篇文章看完：
- 日常在多个分支间切换，经常"带不走"手头半成品改动的同学；
- 参与多人协作，频繁需要拉最新代码，却担心本地改动冲突的同学；
- 提交代码前想先做一次code review，把当前改动暂时从工作区"清理掉"的同学；
- 以及那些已经用过
git stash pop却遇到过冲突，不知道怎么处理的新手。
2. stash核心操作完全拆解：save、push、pop、apply
2.1 基础暂存命令：save与push的前世今生
Git的stash命令，最原始的基础操作是git stash save "描述信息"。比如：
git stash save "半成品：用户头像上传逻辑"执行之后，工作区就干净了。如果你的改动里包含新文件，需要加-u参数：
git stash save -u "半成品：用户头像上传逻辑 + 新工具函数"不过，git stash save在较新版本的Git中属于"过时但保留兼容"的命令。Git官方推荐使用git stash push，因为push的语法更开放、更灵活。最典型的用法是只暂存指定的文件，而不是一股脑全存：
git stash push -m "只暂存这个文件" src/utils.js这个操作就非常精准了。工作区里有五个文件改动，你可能只想先存住一个，其他四个继续保留在工作区继续折腾。git stash push -- <路径>用法很值得记住。
还有一点，Git版本越低，save和push在细节行为上的差异越大。如果你还在用2.13之前的Git（不太可能，但保不定公司服务器上装了个远古版本），就直接用git stash save，别折腾push。
2.2 恢复变更：pop与apply的真正区别
这是新手最容易搞混的地方。git stash pop和git stash apply都能把你上次stash的内容恢复到工作区。区别在于：
git stash pop：恢复改动，并且从stash列表中删除这个stash记录。git stash apply：恢复改动，但是保留stash记录，你可以反复apply多次。
大多数情况下，你确实需要pop，因为stash这个"临时储物间"就是为了让你临时放一下东西，取出来之后就没必要留着了。但有一种场景，apply更合适：你有多个分支，想把同一份改动的"副本"同时应用到不同分支上。比如你改了一个公共的配置文件，想让feature/A和feature/B两个分支都包含这份改动，就可以先用apply在feature/A里应用一次，再切到feature/B再apply一次。每次应用都不会删除stash记录，非常方便。
再看个细节。git stash pop可以指定恢复哪个stash：
git stash pop stash@{2}是的三号位。stash列表是有编号的，第0号是最近一次stash，越往下越旧。通过git stash list可以查看全部。
2.3 查看与清理：list、show、drop、clear
stash存多了，得知道怎么查看和管理。
- 查看所有stash列表：
git stash list输出大概是这样的：
stash@{0}: On feature/login: 登录模块样式调整 stash@{1}: On master: 临时修复：数字格式化函数 stash@{2}: On feature/user: 用户头像上传逻辑- 查看某个stash里具体改了哪些文件：
git stash show stash@{1}这只会显示文件名，太粗糙。想看具体的diff内容，加-p参数：
git stash show -p stash@{1}- 删除某个stash记录：
git stash drop stash@{1}- 清空所有stash：
git stash clear清理这个操作要非常谨慎。git stash clear会把你所有的stash记录全部删掉，且不可恢复。我认识一个人，就是顺手敲了clear，结果自己攒了一个多月的几个stash全没了，当场石化。所以执行这类命令前，记得先git stash list确认一下。
2.4 从stash创建分支：stash branch的妙用
如果你pop的时候遇到冲突（后面大篇幅讲这个），或者你想在stash基础上继续开发，又不想污染当前分支，那git stash branch是绝佳选择：
git stash branch feature/stash-branch stash@{0}这个命令的逻辑是：以当前HEAD作为新分支的起点，然后在这个新分支里pop这个stash。这样改动就直接应用到一个新分支上了，工作区也干净，stash记录也会被删除。对于"stash pop出现冲突，但冲突不太想解决"的情况，这是一个很好的出路。
3. 进阶玩法：stash与多分支协作的实战配合
3.1 结合rebase：pull时自动stash的配置
前面讲了手动stash，但很多重复性操作其实可以用Git配置省掉。最典型的就是git pull时自动stash。
默认情况下，git pull会拉取远程代码并merge到本地。但如果本地有未提交的改动，某些情况下Git会拒绝pull，提示"Your local changes would be overwritten by merge"。这个时候你只能手动stash再pull，再pop。
有一种配置可以让你直接git pull不用管这些：
git config --global pull.rebase true git config --global rebase.autoStash true这样设置后，git pull会实际执行git pull --rebase --autostash，也就是说：在拉取之前自动stash本地改动，rebase完成后再自动pop回来。整个过程中你甚至感知不到stash的存在，操作非常顺滑。
这个配置结合了rebase和stash两者的优势：本地提交历史是干净的线性结构，同时本地的临时改动也不受影响。很多团队都会把这个作为统一的Git配置标准之一。
3.2 使用-u和-a参数：完整暂存所有状态
前面提到过，默认stash不含untracked文件。想要把新建文件也存进去，用-u（或--include-untracked）：
git stash push -u -m "包含新建文件的改动"还有个-a（或--all），这个连被Git忽略的文件（比如本地的配置文件、IDE设置）也一起存。这是一个更彻底的状态快照。
我在实操中更推荐大家默认使用-u。因为untracked文件往往是新功能里的一部分，如果不用-u，pop回来时你容易漏掉文件，而且新文件不在stash里就意味着如果切换分支出什么问题，它就会一直裸奔在工作区里，安全性很差。
需要注意的是，-a虽然全，但会把被忽略的文件也存走。如果你本地有.env或者IDE的配置文件恰好被.gitignore忽略了，存入再pop之后可能产生一些意想不到的副作用。所以-a要慎用，我就被坑过一次。
3.3 stash与远程协作：同步stash吗
先回答一个很常见的问题：stash能不能推到远程？答案是不能。stash是纯本地操作，它不会进入远程仓库，也不参与commit历史。这个设计是合理的——stash本质是"临时储物间"，不是"传输管道"。
那多人协作时想共享一份"半成品改动"怎么办？正确做法是创建一个独立的分支，把改动提交上去，推送远端，然后让同事拉这个分支。等改完测试完再合并。千万不要试图用stash来做这件事。
3.4 多个stash的管理策略
如果你同时进行几个任务，开了好几个stash，一定要靠描述信息来区分。-m参数别省，尽量写清楚"哪个分支、在做什么、改了什么"，不然一周之后你自己都分不清stash@{3}到底是干嘛的。
我自己的习惯是：
git stash push -m "feat/login: 登录页表单验证逻辑（未完成）" git stash push -m "fix/typo: 修正README中的拼写错误"这样在git stash list里面一眼就能看出来哪个stash是干嘛的。如果有清理需求，也能精准drop某一个。
4. stash pop冲突处理与常见问题排查实录
4.1 pop时为什么会冲突
这是全网搜索热度最高的stash问题，也是很多人在实际工作中最头疼的一块。
你要明白，stash本质上是把工作区和索引的改动存成一个特殊的commit对象。当你执行git stash pop时，Git尝试把这个commit的diff应用到当前工作区。如果当前工作区对应的文件状态，和当初stash时的状态不一致（尤其是同一块代码区域也被其他操作改动了），就会产生冲突。
举一个典型场景：
- 你在feature/login分支改了
login.js，stash了。 - 你切到master修了个bug，顺手也改了
login.js的同一行。 - 你切回feature/login，执行
git stash pop。
这时pop就会报错，提示类似：
CONFLICT (content): Merge conflict in src/login.js别慌，这不是世界末日，冲突解决思路和merge冲突几乎一样。
4.2 冲突后的处理步骤
当你看到冲突提示时，首先确认一下当前的stash记录还在不在。注意一个细节：git stash pop在遇到冲突时，不会删除stash记录。这是Git一个很重要的容错设计——它在给你留退路。
处理步骤如下：
第一步：查看冲突文件。
git status你会看到类似这样的状态：
Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/login.js第二步：打开冲突文件，手动解决。文件里会有明显的冲突标记：
<<<<<<< Updated upstream 原来的代码 ======= stash里的新代码 >>>>>>> Stashed changes需要区分，Updated upstream是当前分支上的内容，Stashed changes是stash带回来的内容。根据自己的需求，保留一部分、合并一部分，或者全部重写。
第三步：逐个文件解决完冲突后，把它们标记为已解决：
git add src/login.js第四步：如果你不想保留这个stash记录了，手动删除它：
git stash drop这里要特别留意：因为pop在冲突时不会自动删除stash，所以你解决完冲突后必须手动drop。不然这个stash记录会一直留在列表里，而且下次再pop又可能冲突。
4.3 老版本Git与新版Git在冲突后的差异
我遇到过不少运行老版本Git（2.x早期版本）的项目环境。老版本在冲突时输出信息比较简略，只有"Conflict"字样，可能没有下一步提示。新手容易以为stash已经成功pop了，结果发现工作区一堆冲突标记，stash也没删，一时间手足无措。
新版Git（2.35及以上）在冲突时会明确提示：
The stash entry is kept in case you need it again.这句提示就非常友好。如果看到这句话，就说明stash还在，你放心解决冲突，解决完了记得手动drop。
4.4 常见问题速查表：stash的十大疑难杂症
我用一张表把实际中常见的stash问题列一下，方便你对照排查。
| 问题 | 可能原因 | 解决办法 |
|---|---|---|
| stash后新建的文件还在工作区 | 没加-u参数，untracked文件未被暂存 | 确认文件，手动处理或重新stash时加-u |
| pop时冲突，stash记录没有被删除 | Git设计如此，为了安全 | 解决冲突，git add后，再git stash drop |
| stash list里看不到stash，但工作区有奇怪改动 | 可能之前有个stash被drop，或autostash残留 | 检查git fsck --lost-found找dangling commit |
git stash pop时提示"could not restore untracked files" | 工作区已存在同名untracked文件 | 先移动或删除同名文件，再pop |
不小心git stash clear，还能恢复吗 | 不能百分百恢复，但有几率通过git fsck找回 | 立刻执行git fsck --lost-found，查找dangling objects |
| 想切分支，但提示本地改动冲突 | 改动涉及切换目标分支中已修改的文件 | 先git stash push -u，再切换分支 |
| pop时提示"already exists, no checkout" | 工作区已有相同路径的文件（untracked） | 手动处理已有文件后再pop |
| 只想存某几个文件 | 用git stash push -- <file>指定路径 | 路径用空格分隔，支持通配符 |
| 多个stash总是搞混 | 没写描述信息 | 下次执行git stash push -m "描述" |
| stash应用后想撤销恢复的改动 | 恢复后改动进入工作区，可用checkout丢弃 | git checkout -- <file>（确认后操作） |
4.5 我踩过的一个深坑：stash与符号链接的恩怨
最后分享一个很少人知道但真实存在的坑。如果你的项目里有符号链接（symlink），stash会对它做特殊处理。老版本Git中，stash一个改动了符号链接内容的状态，pop回来时有可能出现符号链接变成普通文件的情况。我遇到过一回，排查了很久才发现是符号链接在stash转换过程中丢失了文件属性标志。
这个属于比较冷门的知识，但对维护项目基础设施的开发者来说，知道有这回事就能省下大量排查时间。如果你的项目大量使用符号链接，建议升级到最新版Git，并且stash之后做个检测脚本验证关键链接是否完好。
4.6 终极兜底：误删stash的紧急恢复法
还是有必要讲一下，万一真的不小心clear了怎么办。Git本身有一个机制叫"dangling commit"，被删除的commit对象如果没有被gc清理，其实还残留在对象库里。
操作如下：
git fsck --lost-found输出里会出现一堆dangling commit记录。这些commit对象里可能就包含你误删的stash。你可以用git stash apply <commit>尝试恢复。
这个操作不保证一定能找回来，取决于是否执行过git gc或git prune。所以我的建议是：stash里放着重要代码时，别轻易clear。宁可一个个drop，也别用clear一刀切。
5. 把stash用好：我的工作流建议
5.1 什么时候该用stash，而不是临时分支
很多人会纠结，既然有分支，为什么还要stash。其实两者的定位完全不同：stash适合"短时间、临时性、保存状态"，分支适合"长周期、协作性、独立开发"。
如果你只是临时切过去修个紧急bug，5分钟就能回来。这种场景用git stash push -u是最高效的。 但如果你切过去改的东西要改好几天，甚至引来一堆人一起改。那我建议还是老老实实创建一个分支。stash一放放好几天，回来时你自己可能都忘了里面有啥，pop时还容易冲突。
5.2 我的日常Git配置参考
分享一下我的Git全局配置，供参考：
git config --global alias.st "stash" git config --global alias.stash-all "stash push -u" git config --global pull.rebase true git config --global rebase.autoStash true配置完alias.st后，git st list和git st pop用起来非常顺手。配上pull.rebase和autoStash，日常更新代码基本不需要手动stash。
5.3 结尾：一个小建议
我个人的经验是，stash虽然好用，但不要把它当作长期的代码保管箱。它最适合的场景就是"插队"情况下的临时状态保存。如果你发现自己经常好几天都不pop stash，说明你的工作流可能有问题，该开分支的时候还是得开分支。最后一个小提醒：每次git stash pop之后，都习惯性地git stash list看一眼，确保没有多余的stash残留。这个习惯能帮你避免至少一半的stash相关烦恼。
