git stash这个词用过的都说香但真正玩明白的人真不多。工作区改到一半突然要切分支、改bug、拉代码手头这堆改动的去留就成了最闹心的事。本篇文章就从底层逻辑到实操细节把git stash的用法彻底掰开揉碎尤其是stash pop的冲突解决我直接把我踩过的坑和排查思路全给出来你看完就能直接用。1. 为什么需要git stash从日常开发场景说起1.1 工作中最常见的切换中断场景先问你一个场景你正在自己的分支上加一个新功能改了差不多三四个文件里头包括一个公共配置文件的改动。突然测试那边抛了个线上bug优先级拉到最高你必须在五分钟内切到主分支拉个hotfix分支赶紧修复上线。这时候你怎么办直接git checkout masterGit会警告你本地改动会被覆盖。因为你改了文件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、apply2.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可以指定恢复哪个stashgit stash pop stash{2}是的三号位。stash列表是有编号的第0号是最近一次stash越往下越旧。通过git stash list可以查看全部。2.3 查看与清理list、show、drop、clearstash存多了得知道怎么查看和管理。查看所有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}清空所有stashgit 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 结合rebasepull时自动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-untrackedgit stash push -u -m 包含新建文件的改动还有个-a或--all这个连被Git忽略的文件比如本地的配置文件、IDE设置也一起存。这是一个更彻底的状态快照。我在实操中更推荐大家默认使用-u。因为untracked文件往往是新功能里的一部分如果不用-upop回来时你容易漏掉文件而且新文件不在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.jsstash了。你切到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在冲突后的差异我遇到过不少运行老版本Git2.x早期版本的项目环境。老版本在冲突时输出信息比较简略只有Conflict字样可能没有下一步提示。新手容易以为stash已经成功pop了结果发现工作区一堆冲突标记stash也没删一时间手足无措。新版Git2.35及以上在冲突时会明确提示The stash entry is kept in case you need it again.这句提示就非常友好。如果看到这句话就说明stash还在你放心解决冲突解决完了记得手动drop。4.4 常见问题速查表stash的十大疑难杂症我用一张表把实际中常见的stash问题列一下方便你对照排查。问题可能原因解决办法stash后新建的文件还在工作区没加-u参数untracked文件未被暂存确认文件手动处理或重新stash时加-upop时冲突stash记录没有被删除Git设计如此为了安全解决冲突git add后再git stash dropstash list里看不到stash但工作区有奇怪改动可能之前有个stash被drop或autostash残留检查git fsck --lost-found找dangling commitgit 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与符号链接的恩怨最后分享一个很少人知道但真实存在的坑。如果你的项目里有符号链接symlinkstash会对它做特殊处理。老版本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适合短时间、临时性、保存状态分支适合长周期、协作性、独立开发。如果你只是临时切过去修个紧急bug5分钟就能回来。这种场景用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相关烦恼。