Git Stash 实战：临时切分代码、切换分支和找回误删记录
前言
git stash我以前用得很简单，基本就是两条命令。
gitstashgitstash pop正在写功能，突然要切分支修一个紧急问题，就先stash，修完回来再pop。这个用法当然够用，但只适合很干净的场景：当前所有修改都可以一起收起来，回来以后也能一起恢复。
真实开发里经常没这么简单。
有时候一个文件里同时有稳定代码和调试代码；有时候暂存区里已经放好了准备提交的内容，工作区里还有一堆未完成的实验；有时候只想收起某一个文件；还有时候 stash 放久了，回头再apply出现一堆冲突。
git stash的价值不只是临时保存代码。它更适合在工作被打断时，帮开发者把当前修改按粒度拆开，给切换上下文留一个干净出口。stash 本身会记录工作区和暂存区状态，最新记录可以通过stash@{0}引用，之前的记录依次是stash@{1}、stash@{2}。这些记录可以查看、应用、删除，也可以基于原始提交直接创建新分支。
一、先给每个 stash 写清楚名字
很多人 stash 多了以后都会遇到一个问题：列表里全是WIP on xxx，完全看不出来哪一条是什么。
先看列表：
gitstash list常见输出大概是这样：
stash@{0}: WIP on feature-auth: 9f3a1c2addlogin page stash@{1}: WIP on feature-auth: 9f3a1c2addlogin page stash@{2}: WIP on main: 3d21a8f fix layout这种列表看起来很痛苦。真正要恢复的时候，只能一个个show。
更好的习惯是每次保存时带上描述：
gitstash push-m"auth: login form half done"查看某条 stash 的摘要：
gitstash show stash@{0}看完整 diff：
gitstash show-pstash@{0}如果恢复时还不确定效果，先用apply：
gitstash apply stash@{0}确认没问题以后，再手动删除：
gitstash drop stash@{0}pop会在应用成功后删除 stash，apply会保留记录。遇到不确定的修改，我更倾向先用apply。万一恢复后发现冲突或效果不对，还能重新来一次。pop发生冲突时不会自动删除记录，但日常使用里先apply的心理负担更小。
二、只收一部分代码
git stash默认会把当前可保存的修改一起收走，这在很多场景下太粗。
比如我正在写认证功能，同时在同一个文件里加了几行调试日志。现在要切分支处理别的事，但我只想把认证功能收起来，调试日志还想留在工作区继续看。
可以用交互式模式：
gitstash push-p-m"auth: selected login changes"Git 会按 hunk 展示修改，让你逐块选择。
常用选项一般够用了：
y 收起当前块 n 跳过当前块 s 把当前块继续拆小 e 手动编辑当前块 q 退出这个命令适合处理“一个文件里混了多种意图”的情况。比如：
稳定实现代码 临时日志 调试分支 格式化修改 无关文档调整这些内容如果一起 stash，回来以后还是混在一起。用-p可以先把要保留的现场和要临时收起的代码拆开。--patch会交互式选择工作区里的修改，被选中的内容进入 stash，未选中的内容继续留在工作区。它还会隐含保留暂存区状态，必要时可以用--no-keep-index调整这个行为。
如果只想收某个文件或目录，可以直接用路径：
gitstash push-m"auth file only"-- src/auth.ts多个路径也可以一起写：
gitstash push-m"auth and config"-- src/auth.ts config/这类写法对多任务并行很有用。比如当前工作区里同时改了前端页面、配置文件和 README，但你只想临时收起配置文件改动，就不需要把所有内容一起打包。路径参数会让 stash 只记录匹配路径的修改，其他文件保持原样。
三、暂存区和工作区要分开处理
很多人使用 stash 出问题，都是因为没区分暂存区和工作区。
Git 里有三层状态：当前提交、暂存区、工作区。git stash处理的不是一个简单文件夹快照，它会记录工作区状态，也会记录 index，也就是暂存区状态。
一个常见场景是：我已经用git add把准备提交的代码放进暂存区，但工作区里还有没完成的实验代码。现在我只想把暂存区那部分收起来。
可以用：
gitstash push--staged-m"ready changes before hotfix"--staged只保存已经加入暂存区的修改。它有点像把暂存区内容提交到 stash，而不是提交到当前分支。工作区里没有 staged 的修改会继续留着。
反过来，如果我想保留暂存区，只把未暂存修改收起来，可以用：
gitstash push --keep-index-m"unstaged changes"这个用法适合测试部分提交。
比如你在一个文件里做了很多改动，现在想把其中一部分作为一个独立提交。可以先交互式加入暂存区：
gitadd-p然后把剩余未暂存内容收起来：
gitstash push --keep-index-m"remaining changes"这时工作区只剩下已经暂存的那部分内容。你可以单独跑测试：
npmtest测试通过后提交：
gitcommit-m"add auth validation"再恢复剩余修改：
gitstash pop这个流程比“所有修改一起提交”干净很多。尤其是在一个下午同时改了多个点时，add -p加stash --keep-index可以帮你把提交拆得更清楚。--keep-index会在 stash 时保留已经加入 index 的修改。
四、冲突多时直接从 stash 开新分支
stash 放久了以后，最怕恢复。
比如你在feature-auth上 stash 了一批修改。几天后，main 合进来很多更新，相关文件被重构了。这个时候直接：
gitstash apply stash@{0}很可能出现一堆冲突。
这时可以用：
gitstash branch auth-stash-work stash@{0}这个命令会基于创建 stash 时的那个提交创建新分支，再把 stash 里的修改应用上去。应用成功后，如果引用的是stash@{n}这种记录，它还会自动删除对应 stash。
它的好处是恢复环境更接近当时保存 stash 的现场。很多在当前分支上冲突很大的修改，回到原始基点以后就能干净恢复。
我一般会在这些情况下用stash branch：
stash 放了很久 原分支已经经历大量重构 apply 以后冲突太多 stash 里的修改值得继续做成一个独立分支这个命令也适合整理长期遗留的 stash。比如列表里有一个两周前的工作进度，已经不确定还能不能直接恢复，那就开个新分支看：
gitstash branch recover-old-login stash@{2}恢复出来以后，再决定是继续开发、拆提交，还是直接丢弃。
五、自动 stash 可以用，但不要完全依赖
有些开发者喜欢在 rebase 或 pull 时让 Git 自动 stash 当前修改，操作完成后再恢复。
比如一次性命令：
gitpull--rebase--autostash或者设置 rebase 默认自动处理：
gitconfig--globalrebase.autoStashtrue这个能力确实方便。工作区不干净时，也能先临时保存修改，rebase 结束后再自动应用回来。
但我不会把它当成无脑默认策略。
原因很简单：自动恢复也可能出现冲突。特别是你当前修改和上游更新改了同一块代码时，rebase 成功并不代表最后的 stash 恢复一定顺利。git pull --autostash也一样，最后恢复本地修改时可能遇到不小的冲突。
我更建议在两类场景里用：
本地修改很小，比如只改了 README 或一两个配置 你很清楚当前修改和上游更新不太可能冲突如果当前工作区改动很多，尤其是业务代码、迁移文件、锁文件都动了，最好还是手动处理：
gitstatusgitstash push-m"before rebase"gitpull--rebasegitstash apply这样每一步都能看清楚出了什么问题。
六、误删 stash 还有机会找回
误删 stash 很常见。
比如手滑执行了：
gitstash drop stash@{0}或者更严重：
gitstashclear列表清空以后，普通方式就看不到了。但 stash 底层是 Git 对象，只要还没有被垃圾回收清掉，就有机会找回来。
可以先找不可达提交：
gitfsck--unreachable|grepcommit|cut-d' '-f3|xargsgitlog--merges--no-walk--grep=WIP找到可疑提交后，看内容：
gitshow<commit-hash>如果确认是要找的 stash，可以尝试恢复：
gitstash apply<commit-hash>这个方法不保证一定成功，因为不可达对象最终可能被git gc清理。发现误删以后，最好先停下其他 Git 操作，尽快找。stash 条目被drop或clear后，普通安全机制已经不能直接恢复，只能通过不可达对象去碰运气。(Git)
我也建议不要长期把重要工作只放在 stash 里。stash 更适合短期临时保存。真正重要、可能跨天继续的工作，开分支提交 WIP 会更稳：
gitswitch-cwip/auth-refactorgitadd.gitcommit-m"WIP auth refactor"后面需要整理历史时，再用 rebase、squash 或 reset 处理。
七、一个更稳的日常流程
复杂一点的场景可以这样处理。
假设我正在开发用户认证功能，当前状态是：
auth.ts 已经完成一部分，准备提交 database.ts 有临时调试代码 README.md 有一些文档修改 现在需要立刻切到 hotfix 分支修线上问题先看状态：
gitstatus把准备提交的认证逻辑加入暂存区：
gitaddsrc/auth.ts只保存暂存区内容：
gitstash push--staged-m"auth: ready login changes"再把剩余现场收起来：
gitstash push-m"local debug and docs changes"现在工作区干净，可以切换分支：
gitswitch hotfix/database-timeout修完 hotfix 后回到原分支：
gitswitch feature-auth先恢复认证逻辑：
gitstash apply stash@{1}检查没问题后提交：
gitaddsrc/auth.tsgitcommit-m"add login validation"gitstash drop stash@{1}再恢复调试和文档：
gitstash apply stash@{0}这个流程看起来步骤多，但每一步的意图很清楚。稳定代码、调试代码、文档修改没有混在一起。真正恢复时，也能按顺序处理，不会一口气把所有东西倒回工作区。
日常使用里，我会遵守几个简单习惯：
stash 一定写描述 恢复前先 git stash show -p 看内容 不确定时用 apply，确认后再 drop 超过两三个 stash 就整理，不要一直堆 跨天工作尽量开分支提交 WIP 冲突太多时用 stash branch这些习惯能避免很多低级混乱。
总结
git stash最常见的用法是临时收起当前修改，但它真正好用的地方在于能控制粒度。
只想收部分代码，可以用git stash push -p。只想收某些文件，可以在命令后加路径。只想收暂存区，用--staged。想保留暂存区、收起其他修改，用--keep-index。恢复时不确定结果，就先apply，确认后再drop。冲突太多，直接用git stash branch回到创建 stash 时的基点继续处理。
stash 适合短期上下文切换，不适合长期保存重要工作。真正需要跨天保留、需要给别人看、需要参与协作的内容，还是应该放进分支和提交里。stash 用得越多，越要记得定期整理，否则它很快就会变成另一个难以管理的临时仓库。
我的建议很简单：把git stash当成“临时工作台”，不要当成“长期储物间”。紧急切换、拆分修改、处理冲突时用它；重要进度、长期任务、团队协作时回到分支和提交。这样用下来，stash 会变成一个很顺手的缓冲工具，而不是一堆自己也看不懂的WIP on branch。