Git Stash 实战指南：从暂存到恢复，一文搞定代码切换难题

说个每天都在遇到的场景：功能正写一半，代码还没法运行，临时告警响了需要立刻切分支修。commit半成品吧，提交记录里多一条垃圾；不commit切分支吧，要么被Git拦住，要么把改到一半的文件带到别的分支去，搞乱后来人。这种时候，git stash就是我手里最顺手的一个工具。

stash这个词翻译过来是“隐藏、暂存”，但它干的事情比你想象中更聪明：把工作区和暂存区里所有未提交的改动打包，塞进一个专门的“储物柜”，然后让当前工作区回到干净状态。等你忙完手头的事，再一条命令把改动取回来，原封不动地继续写。

这篇文章就围绕stash展开，从最基础的用法讲到冲突排查、误删恢复这类进阶场景。内容基于我一个一个命令实测过的经验，适合刚接触Git的初学者，也适合天天用Git但没深入研究过stash细节的朋友。

1. 为什么说stash是“代码版的暂停键”

想理解stash的价值，先得理解Git工作区的三大状态。改动不是只存在一个地方：工作区是你的实际文件改动，暂存区是你git add后准备提交的内容，本地仓库是HEAD指向的最后一次提交。三者之间任何一层有差异，都可能影响切换分支、拉取代码、合并等操作。

1.1 痛点场景：改了一半代码不能走

举个例子，我正在开发一个登录模块，改了三个文件，还没改完，连编译都不通过。这时线上出现一个紧急问题，需要基于当前分支前端版本立刻修复并发布。如果我直接git checkout fix-branch，Git大概率会弹出Your local changes to the following files would be overwritten by checkout，直接拒绝切换。

如果强行通过git checkout -f切过去，我的半成品改动会被覆盖。不要指望能恢复回来，这个命令执行后丢失就是没了。还有一种解决办法是先把改动commit掉，但这样会在历史记录里留下一个“半成品的提交”，后续不管是rebase还是review都会很难受，代码Review阶段还会被同事追着问“这个提交为什么编译不过”。

1.2 stash的底层原理：它其实是一个特殊的提交

很多人以为stash只是把文件挪了个临时位置，其实不是。stash底层走的是Git对象系统：它会把当前工作区和暂存区的状态分别打包成Git对象，然后创建一个special commit，这个commit被挂在refs/stash引用下面。

每次执行git stash，旧的stash自动变成新stash的parent节点，形成一条栈式的链。这也解释了为什么可以保存多个stash，为什么git stash list看到的是一个从最近到最远的列表，以及为什么能通过git fsck找回一个误删的stash——因为底层毕竟是commit对象，只要没有被垃圾回收，就还有救。

理解了这层原理，后面处理冲突、找回误删stash时，思路会清晰很多。

2. stash基础操作手册：从保存到恢复

先过一遍最常用的命令。这些操作我基本每天都在用，不复杂，但几个参数选择的差别值得记一下。

2.1 三步走：存、查、取

第一个命令是git stash，不带任何参数的默认行为是：把所有已跟踪文件的改动打包，包括工作区的改动和暂存区中已add但尚未提交的改动，然后重置工作区，让文件恢复到你最后一次提交时的状态。

执行后你会发现工作区瞬间变得干干净净，所有未提交的改动从当前工作区消失。git status干净到让你一度怀疑自己是不是白写了半天代码。不用慌，改动没有丢，静静躺在stash栈里。

第二个命令是git stash list，用来查看“储物柜”里有什么：

bash复制git stash list
# stash@{0}: WIP on main: 2a4f8c1 完成登录页面基础布局
# stash@{1}: WIP on dev: 9b3d7e0 修复接口超时问题

列表里按倒序展示所有stash记录，最近的排在最上面。如果你没有给stash写描述，默认的命名格式是WIP on branch名: commit hash 提交信息，看到这种标题你大概能猜出自己的改动是哪个阶段的，但如果存了好几个甚至跨了好几天，这个默认描述就不够用了。给stash加描述信息是很有必要的习惯，后面会讲。

第三个命令是取回改动，这里有两种方式，对应两个不同的场景：

bash复制git stash pop     # 取回栈顶stash，并把它从栈中删除
git stash apply   # 取回栈顶stash，但保留在栈中

差别在哪？pop是“取走”，处理完正常情况下的一个stash生命周期就结束了；apply是“复制一份”，stash原封不动还在栈里，适合你同一份改动想放到多个地方用的场景。

2.2 给stash加备注

之前那种默认的stash命名，对于存两三个stash的情况还够用，但当你同时处理多个任务、多个分支时，光靠默认描述根本分不清那是哪天的改动。所以必须养成写备注的习惯。

推荐写法：

bash复制git stash push -m "登录模块-验证码倒计时功能未写完"

-m参数就是给stash加描述。执行后git stash list输出变成：

bash复制stash@{0}: On feature/login: 登录模块-验证码倒计时功能未写完

一眼就能看出这个stash对应的任务、涉及内容和完成状态。这里多说一句，git stash完全等价于git stash push，但显式写push更清晰，后面还可以直接带路径参数，比如只stash指定文件。

2.3 save还是push，老命令和新命令的取舍

如果你看过一些老教程，会有git stash save "描述"这种写法。save是早期版本的用法，现在Git官方推荐使用push替代，两者功能基本一致，但push的扩展能力更强，可以直接在命令里追加路径限定和参数选项。我用git stash不带参数或者git stash push -m带描述，不会再用save，反正只是打字习惯问题，新版Git兼容旧命令，但没必要再学旧习惯。

还有一点要注意，git stash默认只stash“已跟踪文件”的改动。如果你新建了一个文件，还没git add过，它在Git眼里是个未跟踪文件（untracked），默认情况下git stash不动它，它会原封不动留在你的工作目录里。这个特性的好处是你的新文件不会被误藏起来，坏处是如果你希望把新文件一起藏起来，默认命令就实现不了，需要用到后面第3.1节里的参数。

3. 进阶场景：让stash适配复杂需求

基础操作能覆盖80%的场景，但我下面要讲的几个参数和命令组合，才是stash真正拉开体验差距的地方。

3.1 把未跟踪的新文件也纳入stash

这是最常用的参数，没有之一。新建的文件不git stash的默认范围里，但很多时候你新建的文件才是整个功能的核心。比如我改动了两个旧文件，还写了一个新模块user_auth.go，如果直接git stash切走，旧文件改动被藏起来了，新文件还留在工作区，到了目标分支一看，怎么多了一个跟当前分支完全无关的文件？很容易污染提交范围。

解决方案是加参数：

bash复制git stash push -m "紧急bug修复前暂存认证模块" --include-untracked

--include-untracked，简写是-u，会把所有未跟踪的新文件一起打包进stash。这样切分支后工作区完全干净。

还有一个参数是--all，它比-u更极端，会把未跟踪文件和忽略文件（比如gitignore里排除的日志、编译产物、临时文件）也一起打包。我很少用--all，因为把编译产物藏起来反而麻烦，恢复时还可能覆盖到新生成的缓存，导致权限或路径报错。一般来说，-u已经足够满足需求。

3.2 从stash直接创建分支

这个命令是我个人非常喜欢的一个冷门技巧。很多时候，你stash的时候是在老分支上，隔了几天再来处理这个stash时，老分支已经被其他人改得面目全非。这时直接git stash pop，十有八九会跟你现在的工作区撞车，产生一堆冲突。

更稳妥的做法是用git stash branch：

bash复制git stash branch feature/login-stash-v2 stash@{0}

这条命令会基于你创建这个stash时的那个commit，自动创建一个新分支并切换过去，然后在干净状态下应用栈顶的stash。效果等于“回到过去的某个状态处理未完成的改动”，不打扰当前分支上其他人新提交的内容。

我用这个命令解决过不止一次“stash跟当前代码差异太大，pop出各种冲突”的情况。如果冲突根源是上下文发生了太大变化，与其硬着头皮在一个错误基础上解决冲突，不如用stash branch回到基于原commit的分支上去处理，更安全。

另外，git stash show可以查看某个stash的改动摘要，加-p参数可以看到具体diff内容。在决定要pop还是branch之前，先看一眼这个stash的影响范围，属于成本极低的预查动作：

bash复制git stash show -p stash@{0}

3.3 处理暂存区与工作区分离的stash --keep-index

有一个场景比较隐蔽：你git add了两个文件，这部分内容确认好了准备提交，但你又改了第三个文件，也还没改完。现在需要切分支救急，你希望的是：已确认的部分继续留在暂存区（因为没提交完），未完成的部分被stash起来。

直接git stash会把暂存区和工作区的改动全部打包，切回来之后没法区分哪些是已确认的、哪些是半成品。这时需要用--keep-index参数：

bash复制git stash push --keep-index -m "暂存未完成的新改动，保留已add确认的内容"

执行后，已git add的改动会被保留在暂存区，工作区中其他未add的改动被藏起来。这个命令适合做“分阶段提交”时用，先确认一批，藏好另一批，提交完第一批后再恢复第二批继续开发。

不过使用频率上比-u低很多，但遇到这个场景时必须知道有这么个选项。

4. stash pop出现冲突的完整处理流程

热搜词里就有“git stash pop 出现冲突”，这确实是被问得最频繁的问题。很多人的第一反应是“完了，我的代码炸了”，其实这是Git的正常保护机制，处理流程是固定的、可预测的。

4.1 冲突是怎么来的

stash pop本质上是一次合并操作。它会把你stash时的改动，跟当前工作区的状态进行合并。如果从保存stash到恢复stash之间，目标代码没有发生变化，Git能自动完成合并，一切顺利。但如果这段时间里某个文件在另一条分支上被修改过、提交过，两边在同一行附近出现了不同改动，Git就无法判断该保留谁，只能停下来让你手动选择。

发生冲突时，终端会输出类似CONFLICT (content): Merge conflict in src/index.js的提示，并且工作区里的冲突文件会被标记出冲突区域。

4.2 七步解决stash冲突的参考流程

我在实际项目中走过很多次这个流程，整理一下操作性最强的步骤：

第一步，确认冲突文件。git status会列出所有冲突文件，所有标为both modified的文件都需要处理。

第二步，打开冲突文件，搜索冲突标记。冲突区域通常是：

javascript复制<<<<<<< Updated Upstream
// 当前工作区的代码
=======
// stash里的代码
>>>>>>> Stashed changes

三段式标记。中间=======把两部分分隔开，上面是当前工作区已有的内容，下面是stash里保存的内容。

第三步，手动合并。逐行判断应该保留哪边，或者把两边内容都整合。这一步没有任何自动化工具能替你决策，业务逻辑只有你清楚。合并完记得把<<<<<<<、=======、>>>>>>>这些标记全部删掉，一个不剩。

第四步，对这个文件执行git add，把冲突标记为已解决。

第五步，重复以上操作，处理完所有冲突文件。

第六步，也是最容易被忽略的一步：执行git stash drop。很多人不知道，当git stash pop遇到冲突时，stash条目并不会自动从栈中删除。Git故意保留它，就是怕你解决冲突失败后还能有退路。所以冲突解决完并且add之后，需要手动执行以下命令清理栈：

bash复制git stash drop stash@{0}

这个时候才真正放心，改动已经完整地回到了工作区，stash的使命也结束了。

第七步，正常继续。add完以后可以直接commit，或者继续修改，看实际情况决定。

4.3 如果冲突太复杂，可以回滚重新来

如果打开冲突文件发现两边差异太大，理顺成本太高，还有一个“后悔药”：直接git checkout -- 冲突文件或者git restore 冲突文件，把这些文件恢复到pop之前的状态，然后重新git stash apply，换一种方式处理。

我自己遇到复杂冲突时会这么处理：先判断差异量级，如果只有十几行冲突，直接手工会更快；如果冲突面覆盖了几百行，我会考虑先放弃这次pop，用git stash branch创建一个专门的分支去处理，或者把我的改动单独抽出来，重新基于最新代码写一遍更实际的逻辑。

4.4 取回部分stash内容的方法

还有一个用得上的小技巧，如果你只想从stash里恢复某一个文件，而不是全部改动，有几种做法。

方法一：先git stash show列出改动文件清单，再用git checkout stash@{0} -- path/to/file把指定文件取出来。这样不会影响其他文件的stash状态，stash条目也还在。

方法二：如果想在恢复的同时顺便剔除某些文件，可以先git stash pop，然后对不需要的文件执行git checkout -- 文件丢弃。这两种我都在用，个人感觉方法一操作更可控。

5. 我在实际项目中踩过的坑和总结的习惯

基础知识讲完了，这节分享一些踩出来的经验。这些细节在很多教程里不会展开讲，但实际工作中往往就是决定你体验好坏的关键。

5.1 误删stash后的恢复操作

先说个踩过的坑。有一次我在仓库里存了一个已经改了三天的重要stash，当时是在main分支上救急存的。救急完成后我执行了git stash pop，从提示信息看起来一切正常，但打开代码发现改动不全。再看了一眼git stash list，完了，那个stash已经被pop删了。

当时我一度以为改动丢了，后来想起来了：stash底层也是一个commit对象，被删除的commit对象并没有立即从磁盘上消失，而是变成了不可达对象。可以通过重新引用它来恢复。

操作步骤是这样的：

bash复制git fsck --unreachable | grep commit

这条命令会列出所有当前没有任何引用指向的commit对象，从中找到对应的时间点和提交信息的对象。找到之后把这个commit应用到当前分支上：

bash复制git stash apply <commit-hash>

这个方法应用到误删的场景还算好用，但时间紧迫时不建议临时查。强烈建议养成定期查看习惯：每完成一个任务节点，就立刻git stash pop，不要长期把多个重要改动堆在stash里。stash是临时存放，不是备份机制。

5.2 组合技巧：stash配合rebase或pull

在另一个场景下也常用stash。当你本地改了代码，而远程分支有了新提交，直接git pull可能会因为本地未提交的改动而失败。这时标准的解法是：

bash复制git stash push -m "pull前暂存本地改动"
git pull --rebase
git stash pop

这样先把本地半成品放到一边，拉取远程最新代码，再把本地改动恢复出来。冲突就在这里处理，也不会污染提交记录。这种组合方式我基本每天都在用，稳定性很高。

5.3 stash的管理习惯

最后聊聊管理习惯。如果经常使用stash，记住几条纪律：

第一，每次stash一定要写-m描述，包括任务名称和当前状态，避免三天后自己都看不懂。

第二，stash的保存上限不要太高。除了极少数跨分支实验的需求，超过5个stash就该检查一下里面是不是有已经过期的改动。定期git stash list查看，对无用条目执行git stash drop。

第三，关键改动不要只依赖stash备份。如果某个文件改动真的很重要，建议先commit到自己的功能分支上，通过push到远程来备份，stash适合存放那些价值不够高但又不忍心丢的中间状态，而不是重要的核心资产。

5.4 一个不建议的用法

最后提醒一下，不推荐把stash当作跨机器同步改动的手段。有些人会想，在本机stash之后，到另一台电脑上怎么把变更同步过去？stash默认只存放在本地仓库里，不会出现在远程。正确的做法是推送到一个临时分支，或者用最近合入的功能分支，或者直接把改动复制到新分支上提交。stash的定位是本地开发应急工具，不是跨设备同步工具。

后来我养成了一个习惯：每次需要临时切换分支时，先看当前工作区的状态，再想清楚到底需不需要stash。有些小改动根本没有保存价值，直接丢弃重写也比之后处理一堆冲突来得快。stash不是所有场景的最优解，但在“代码改到一半，被各种杂事打断”的日常里，它确实是最好用的暂停键。