Git Stash丢失后的完整找回指南实用指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Git Stash丢失后的完整找回指南”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

场景：本地分支有未提交的 git stash，合同时远程分支后 stash 从列表消失，代码"不见了"。

事故还原

1. 在本地分支 test-eslint-copy 上做了大量修改（props 清理、字段删除等）
2. 用 git stash 暂存了这些改动
3. 执行 git merge origin/test 合同时远程分支
4. 合同时后发现 git stash list 里没有了自己的 stash，改动"消失"

根本原因：git stash 的记录存储在 refs/stash 引用链上。某些 git 操作（如带冲突的 merge、reset 等）会导致 stash 引用丢失，但 stash 的 commit 对象本身还在 git 对象库里结合项目来看，，只是变成了"悬空对象（dangling commit）"，没有任何引用指向它。

找回步骤

第一步：确认 stash list 里真的没了

git stash list

若你的 stash 不在里面，继续下一步。

第二步：用 fsck 找出所有悬空的 commit

git fsck --unreachable 2>&1 | grep "unreachable commit"

这会列出所有"孤儿 commit"，stash 就藏在里面。

第三步：过滤出属于你分支的 stash

落到代码里，stash commit 的 message 格式固定为 WIP on <分支名>: <hash> <commit message>，用这个特征过滤：

git fsck --unreachable 2>&1 | grep "unreachable commit" | awk '{print $3}' | while read c; do
  msg=$(git log -1 --format="%s %ci" $c 2>/dev/null)
  if echo "$msg" | grep -q "WIP on <你的分支名>"; then
    echo "$c | $msg"
  fi
done

把 <你的分支名> 替换成实际分支名，比如 test-eslint-copy。

输出示例：

469b4f36... | WIP on test-eslint-copy: 23996d8 fix: 再次处理eslint问题 2026-04-28 10:03:30 +0800
bcb74bf5... | WIP on test-eslint-copy: 14aa429 Merge branch 'test' 2026-04-28 09:54:12 +0800

第四步：确认是不是你要的那个

根据时间戳判断，然后看改动内容：

git show <commit-hash> --stat

第五步：恢复

先处理工作区的干扰文件（如果有），再 apply：

# 如果有自动生成的文件挡路，先丢弃
git checkout -- src/dts/auto-imports.d.ts src/dts/components.d.ts

# 恢复 stash
git stash apply <commit-hash>

关键原理

预防措施

合并前养成习惯：

# 合并前先把 stash 转成真正的 commit
git stash pop
git add .
git commit -m "wip: 临时保存"

# 合并完再 reset 回来
git merge origin/xxx
git reset HEAD~1  # 把临时 commit 变回工作区改动

或者更轻松，用 --autostash：

git merge --autostash origin/xxx

这样 git 会在合同时前自动 stash、合并后自动 pop，不会丢。

总结一句话

stash 丢了不要慌，git fsck --unreachable 找悬空 commit，按时间戳认出来，git stash apply <hash> 直接恢复。只要没跑 git gc，数据就还在。

到此这篇关于Git Stash丢失后的完整找回指南的文章就介绍到这了,更多相关Git Stash丢失找回指南内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！