Recovery
找回“消失的 stash”
当 stash 列表里看不到之前保存的内容时，先判断是 pop 后丢失、误删还是引用漂移，再用 reflog 与 dangling commit 进行恢复。
- 正在处理 Git 误操作的人
- 想提前建立保守恢复习惯的协作者
- 先停手，不继续乱试命令
- 能执行 `git reflog`、`git status`、`git log --graph`
- 还没保住旧位置就继续 reset / rebase
- 在没判断影响面时直接改共享历史
引用与延伸阅读
- Git stash [官方]
- Git reflog [官方]
- Git fsck [官方]
学完这篇你会掌握什么
- 理解 找回“消失的 stash” 的核心作用和适用场景
- 掌握 找回“消失的 stash” 的基本用法和常用参数
- 当 stash 列表里看不到之前保存的内容时，先判断是 pop 后丢失、误删还是引用漂移，再用 reflog 与 dangling commit 进行恢复。
- 理解 先判断是哪类丢失 相关的概念
- 掌握 第一轮检查 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
stash 看起来“消失”时，最常见场景不是永久丢失，而是引用不在 stash list 里了。
先想一个问题
你刚刚在 Git 里做了一个操作，结果发现不是你想要的效果——甚至可能弄丢了提交。这种情况不是第一次了，你想建立一套可靠的方法来应对各种误操作场景。
先判断是哪类丢失
git stash pop后冲突/误操作导致看不到- 手动
drop/clear过 - 引用变化后 stash 提交仍在对象库里
stash 历史
HEAD@{3}HEAD@{2}HEAD@{1}当前
找回操作
rescue/recover
第一轮检查
git stash list
git reflog show stash
git reflog
如果 stash 引用还在，优先从 reflog 定位旧条目。
当 stash list 为空时怎么做
可以尝试从 dangling commit 里找 stash 相关提交：
git fsck --no-reflog | rg dangling
然后逐个查看候选提交：
git show <commit>
找到后先建救援分支：
git switch -c rescue/stash-recovery <commit>
恢复策略
- 只要补丁：
git show <commit> > rescue.patch - 要完整恢复到工作区：
git stash apply <stash-ref>或从救援分支 cherry-pick
直接在当前工作分支反复 apply/pop，容易把恢复现场越弄越乱。先把证据固定住再操作更稳。
常见误区
- 误以为
pop等于“安全移动”，其实它会删除 stash 引用 - 在未确认目标提交前执行
gc，增加恢复难度 - 恢复时直接覆盖当前分支，缺少对比空间
接下来建议继续看什么
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：