Siyang先讲一个我自己的真实经历。
那天周五下午，项目交付前最后一次联调。同事在终端里敲了一行 git checkout .，本意是丢弃一个临时调试文件，结果因为当前分支的工作区里堆了太多没有提交的修改，一瞬间整个模块的代码全被还原回了上次提交的状态。大概三秒钟的沉默之后，办公室里响起了一声哀嚎："我两天的工作没了。"
我过去看了一眼，说："别慌，能救。"然后用了不到三十秒，把他的代码完整恢复了出来。
这不是我有多厉害，而是 Git 本身就给每一次操作留了"后悔药"。问题在于很多人平时只管 add、commit、push，从来不知道这些"后悔药"放在哪里、怎么吃。这篇东西我就把 Git 误删恢复这件事讲透，从最简单的场景到最麻烦的极端情况，全部基于我实际踩过的坑和验证过的命令，你可以直接照着操作。
1. 为什么会"误删"：先搞懂 Git 的三个仓库和两条后悔路径
1.1 工作区、暂存区、版本库：Git 不是一块硬盘，是三块叠在一起的硬盘
很多人觉得 Git 就像网盘，存了个快照，想恢复就恢复。这个理解不能说错，但会让人在真正遇到问题时无从下手。真正用好 Git 的恢复能力，必须先理解它的数据组织方式。
Git 把项目状态存在三个地方：
- 工作区（Working Directory）：你电脑上实实在在能看到的文件，编辑器里改的就是这一层。
- 暂存区（Index / Staging Area）：执行
git add之后文件进入的地方，相当于"准备提交的待办清单"。 - 版本库（Repository）：执行
git commit之后文件永久落盘的地方，也就是.git目录里存的那一堆压缩对象。
你可以把这三个区域想象成一个三层抽屉。第一层抽屉放着你正在写的草稿，第二层抽屉放着你已经整理好准备寄出的文件，第三层抽屉是已经盖了邮戳、进了档案室的存底。误删文件，本质上就是某一层抽屉里的东西不见了，而 Git 的恢复能力，取决于你丢的是哪一层抽屉里的东西。
大部分"误删"发生在第一层到第二层之间，也就是你改了代码、还没 commit，然后一个 checkout .、git stash、git reset --hard 把工作区的修改全冲掉了。而这种场景恰恰是最好恢复的，原因在于 Git 的对象库设计。
1.2 对象库机制：Git 为什么能做到"删了还能找回来"
Git 的核心是一个内容寻址的文件系统。每当你 git add 一个文件，Git 会计算这个文件内容的 SHA-1 哈希值，然后把内容以"blob 对象"的形式写进 .git/objects 目录。只要你 add 过，这个 blob 对象就存在了——哪怕你后面又改了文件、又重新 add，旧的对象也不会被立刻删除，而是变成"悬空对象"躺在对象库里。
同理，每次 commit 会生成 commit 对象和 tree 对象，这些对象之间通过哈希值互相引用，形成一条链。HEAD 只是一个指针，指向当前分支的最新提交。
这意味着什么？意味着 Git 的"删除"大部分时候不是真正的物理删除，而是"引用丢失"。文件内容还在对象库里躺着，只是没有东西指向它了。你要做的，是找到那个对象，重新把引用建起来。
这就是 Git 恢复能力的底层原理。理解了这一点，你就明白为什么 git reflog 和 git fsck 能救命，也明白为什么有些场景恢复不了——因为那些对象真的被垃圾回收（git gc）清理掉了，或者你改动的文件从来没有被 Git 跟踪过。
1.3 两条后悔路径：reflog 和对象库扫描
Git 的恢复工具可以分成两条路径：
- 引用日志（reflog）：记录
HEAD指针的每一次移动。你做过什么操作，它都记着。git reset --hard之后想回头，靠它。 - 对象库扫描（fsck）：直接遍历
.git/objects目录，找出没有被任何引用指向的悬空对象。你连 reflog 都