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 都被清了，靠它。
简单说，reflog 是"操作后悔药"，管的是"我刚刚做了什么，我想退回操作前"；fsck 是"数据打捞"，管的是"对象还在，但没有人引用它了"。两条路径搭配使用，基本能覆盖 95% 的误删场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三十秒急救流程：按场景对号入座的恢复命令
2.1 场景一：改了没提交，被 git checkout . 或编辑器覆盖
这个场景最常见，恢复也最简单。只要你 git add 过（哪怕没 commit），文件内容就一定在对象库里。
第一步，先看一眼当前状态：
bash复制git status
如果显示的是 deleted 或者 modified，说明文件还在 Git 的跟踪范围内，直接恢复：
bash复制# 恢复工作区文件到上次 add 或 commit 的状态
git checkout -- <文件名>
# 或者用新版命令（Git 2.23+ 推荐）
git restore <文件名>
# 恢复整个目录
git restore .
注意前提：你 git add 过，恢复的是暂存区里的版本。如果连 add 都没做过，工作区的改动是没有任何版本记录的，神仙也救不回来。这是 Git 恢复的第一条铁律：Git 只能恢复它"见过"的内容。
2.2 场景二：commit 之后发现写错了，想回到上一个版本
你已经 git commit 了，但发现提交里有问题，或者想直接回到上一个提交，这时候误用了 git reset --hard 也不用慌。
bash复制# 查看提交历史
git log --oneline
# 查看所有提交历史（包括被 reset 掉的）
git reflog
git reflog 输出里会有类似这样的记录：
code复制a1b2c3d HEAD@{0}: reset: moving to HEAD~1
f9e8d7c HEAD@{1}: commit: 修复登录模块的 bug
HEAD@{1} 就是你执行 reset 之前的位置。恢复：
bash复制git reset --hard HEAD@{1}
这一下，你的代码就回来了。整个过程不超过十秒，前提是你知道 reflog 这个东西。
2.3 场景三：代码已经 push 到远程，被同事或自己强制覆盖
这种情况麻烦一点，因为远程分支也被改掉了。但好消息是，如果你在本地执行过 git pull、git fetch、git clone，那些被覆盖的提交实际上还在本地的对象库里，只是可能被 reflog 记录了。
bash复制git reflog # 找到被覆盖前的提交哈希
git checkout <哈希> # 或者直接基于这个哈希开一个新分支
git branch recover-branch <哈希>
然后把新分支推送到远程：
bash复制git push origin recover-branch
如果你有权限，也可以把远程的 master 分支强制推回旧状态。但我不建议在多人协作的分支上直接 push --force，更稳妥的做法是开一个恢复分支，让团队成员自己核对、挑选需要的代码。
2.4 场景四：整个文件被 git rm 或者物理删除
误删了文件，还执行了 git rm，甚至已经 commit 了。只要提交还在，恢复方法就很简单：
bash复制# 从上一个提交中恢复文件
git checkout HEAD~1 -- <文件名>
# 或者从任意一个包含该文件的提交中恢复
git checkout <哈希> -- <文件名>
注意 git checkout <哈希> -- <文件名> 的组合，它不会切换分支，只会把指定提交里的文件内容取出来，覆盖到当前工作区。这是一个非常实用的技能，我经常用它来"偷"历史版本里的某一段代码。
2.5 把 30 秒急救流程整理成一张决策表
| 你遇到的情况 | 使用的命令 | 原理说明 |
|---|---|---|
| 改了没提交，被 checkout/覆盖 | git restore <文件> |
从暂存区或 HEAD 恢复文件 |
| 已经 add 但没 commit | git restore --staged <文件> |
从暂存区恢复到工作区 |
| commit 后误操作 reset --hard | git reflog + git reset --hard <哈希> |
回滚 HEAD 指针的移动 |
| 整个分支被删 | git reflog + git branch <新名> <哈希> |
从引用日志重建分支 |
| 文件被 rm 并已 commit | git checkout <哈希> -- <文件> |
从历史提交提取文件 |
| 本地和远程都被覆盖 | git reflog 找哈希 + git push origin <分支> |
基于本地对象库重建远程 |
这张表我贴在了工位旁边。遇到问题先看表，不要凭感觉乱敲命令——乱敲命令本身就是事故扩大的原因之一。
3. 进阶场景：reflog 也失效了怎么办
3.1 使用 git fsck 找回悬空对象
reflog 不是万能的。默认情况下，reflog 的记录会在 90 天（不可达对象）或 30 天（可达对象）后过期清理。如果你的误删发生在一个月前，或者你莫名其妙跑了 git reflog expire，reflog 就指望不上了。
这时候用 git fsck。这个命令的全称是 "filesystem check"，它能扫描整个对象库，找出所有没有被任何引用指向的悬空对象。
bash复制git fsck --lost-found
输出会包含类似这样的内容：
code复制dangling commit a1b2c3d4e5f6...
dangling blob f9e8d7c6b5a4...
dangling tree 1234567890ab...
dangling commit 是最有价值的，因为它代表一个完整的提交快照。你可以用 git show 查看这个提交的内容，确认是不是你要找的代码：
bash复制git show a1b2c3d4e5f6
如果是，就把它变成分支或者 cherry-pick 到当前分支：
bash复制git branch recover a1b2c3d4e5f6
# 或
git cherry-pick a1b2c3d4e5f6
3.2 找回悬空的 blob：文件级别恢复
如果 git fsck 输出里只有 dangling blob，说明你只丢了一个或几个文件的内容，没丢整个提交。这种情况恢复起来稍微麻烦一点，因为 blob 对象本身不包含文件名信息，你需要逐个检查内容。
一个快速的方法是逐个查看 blob 的元信息和内容：
bash复制git cat-file -p <blob哈希>
或者用 git show <blob哈希> 把内容打印出来，结合 git log 的上下文判断它是哪个文件。内容多的话可以重定向到文件里：
bash复制git show <blob哈希> > recovered_file.txt
然后对比内容确认后，再改回正确的文件名。
3.3 场景：git gc 已经跑过了，还能恢复吗
git gc 会把悬空对象清掉，跑完基本就找不回来了。但如果你在 git gc 之后马上发现，还有一个极小的窗口期——有些对象可能因为文件系统层面还没有被覆盖，理论上还有工具能扫描。
现实中我遇到的情况是：只要过了几分钟，对象基本就没救了。所以 git fsck 这个命令越早跑越好，别拖。
3.4 从 IDE 本地历史里找：最后的保命稻草
如果 Git 层面已经彻底找不回来了，还有一条路——IDE 的本地历史。
IntelliJ IDEA 有一个 Local History 功能，默认会记录文件的历史快照；VS Code 装了 Local History 插件的话也有类似能力。路径一般在这里：
- IDEA：右键文件 → Local History → Show History
- VS Code：需要安装 Local History 扩展，文件变动时自动存快照
这个功能连 Git 都没提交的内容也能恢复，因为它是在 IDE 层面独立记录的。我有一次帮同事恢复代码，Git 层面已经干干净净了，最后就是从 IDEA 的 Local History 里找回来的。所以，对于关键项目，我强烈建议把 IDE 的本地历史保留时间调大，默认的 5 天改成 30 天。
4. 常见问题排查与实操避坑
4.1 为什么我的 git reflog 是空的
首先，reflog 是有默认时间窗口的。其次，你查看的 reflog 和你想要恢复的仓库可能不是同一个。还有一种情况：新克隆下来的仓库默认是 bare 还是非 bare 会决定 reflog 的创建方式，但最常见的还是时间窗口问题。
bash复制# 查看 reflog 的过期时间设置
git config gc.reflogExpire
git config gc.reflogExpireUnreachable
如果想避免 reflog 过期导致无法恢复，可以把时间调长：
bash复制git config gc.reflogExpire 180.days
git config gc.reflogExpireUnreachable 90.days
4.2 恢复后分支指针乱掉，怎么整理
执行 git reset --hard 恢复旧提交之后，你的分支会落后于远程分支。如果你改动过的东西需要保留，最好先建一个新分支来保存，再决定如何合并或者强推：
bash复制git branch backup-branch HEAD # 先存一份
git reset --hard origin/master # 再对齐远程
先把恢复的成果存到一个备份分支上，再操作其他事情，永远是最稳的。别在刚恢复完、心还在跳的状态下，接着做复杂的 merge 或 rebase——我见过太多人刚救回代码，又一个 checkout 给弄没了。
4.3 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
git status 显示文件 deleted，但没改过 |
误执行了 git rm 或物理删除 |
git restore <文件> 或 git checkout HEAD -- <文件> |
git reflog 只能看到最近几条记录 |
reflog 过期或被清理 | 用 git fsck --lost-found 扫描悬空对象 |
git fsck 什么也没输出 |
对象被 git gc 清掉了 |
尝试 IDE Local History 恢复 |
| 恢复到了一条"提交在，但文件内容不对"的状态 | HEAD 指向不正确 | 用 git log --all 或 git fsck 找真正包含文件的 commit |
不小心在错误的目录执行了 git reset --hard |
操作了非目标仓库 | 立刻用 git reflog 回退，不要在没确认前继续操作 |
4.4 实操避坑清单
-
不要连续执行多个破坏性命令。 你发现代码丢了，第一反应是试一个好使的命令，结果没反应，又敲一个，又把 reflog 的栈顶覆盖了。先停下来，用
git reflog看清楚再动手。 -
不要在恢复前先跑
git fetch或git pull。 这样做可能把本地分支往前推，让旧提交更难访问。恢复前保持仓库"冻结"是最优策略。 -
git checkout .只在确认不要所有改动时才用。 很多误删事故都是从这条命令开始的。想要丢弃单个文件的改动，指定文件名，别用通配符。 -
给重要的分支打 tag。 一把
tag是稳定的引用，reflog 可以被清理，tag 不会。交付前打一个release-xxx的 tag，等于给代码买了一份额外的保险。 -
不要把
.git目录加入任何云同步工具。 我见过有人把整个项目文件夹放进云盘同步，结果误删文件后，云盘把.git的旧版本也同步覆盖了，等于把最后一条退路也堵死了。
5. 救回代码之后：让"误删"不再是事故
5.1 用 branch + commit 小步快跑，替代侥幸心理
恢复代码只是把损失找回来，真正的问题在于：为什么你会误删？大部分情况下，是因为在一个分支上堆了太多未提交的修改，或者提交颗粒太大，导致你根本不知道哪些改动是安全的、哪些是危险的。
我的建议是：在做任何有风险的操作之前，先建一个分支或者打个 tag，把当前的完整状态存下来：
bash复制git branch backup/2024-xx-xx-before-refactor
这个操作只需要一秒钟，但它能让你在接下来的所有操作中拥有"随便造"的底气。就算执行错了，一条命令回到备份分支就完事了。
5.2 用 git reflog 保存现场：提交前先确认状态
养成好习惯：提交前用 git status 和 git diff 确认你要提交哪些内容，别用 git add . 一把梭。git add . 会把临时文件、配置文件、甚至 .env 密钥文件一股脑加进去，等你想撤销的时候，又是一场混乱。
5.3 把关键文件纳入"保护圈"：.gitignore 的正确用法
另外一个常被忽略的问题是：很多人把不该跟踪的文件（比如数据库文件、密钥、临时脚本）也放进了 Git，导致每次误删牵涉面特别大。正确的做法是维护好 .gitignore，把无关文件排除在版本控制之外：
text复制# 示例 .gitignore
node_modules/
dist/
.env
*.log
这样 Git 就不会去跟踪、恢复、或者意外覆盖这些文件，你的"恢复面"会干净很多，也不容易在 git checkout . 的时候把好不容易调好的配置文件一并冲掉。
5.4 远程仓库才是真正的保险：push 频率要合理
不要等一个功能全写完才 push 一次。我见过很多本地开发一周不 push，然后执行 git reset --hard 把整个星期的劳动清空的。保持频繁的 push 到远程，不仅是团队协作的需要，更是个人代码安全的保障。只要远程有了，就算本地 .git 目录彻底损坏，你还能 git clone 回来。
6. 总结时的几句真心话
敲完上面这些命令，我自己也重新模拟了几遍各种误删场景，确认这些操作跟记忆里一致，可以放心用。作为一个经历过多次"代码秒没"现场的人，我的最终体会是：Git 这套恢复体系非常强大，但前提是你得"用得上"它。
所谓用得上，就是你养成好习惯，让 Git 随时知道你的代码状态。未提交的改动是脆弱的，提交后的代码是坚强的。每次你想丢弃改动、强推分支或者清理工作区的时候，先花几秒钟想想：我这一步操作会把什么引用弄丢？有没有可能先建个分支存一下？
最后再分享一个压箱底的习惯：每当我要执行 git reset --hard、git branch -D、git clean -fd 这类命令时，我会先在终端里敲 git reflog 看一遍当前的位置，再执行操作。 这个习惯看起来啰嗦，但它让我避免了至少五次深夜抢救代码的惨剧。
如果这篇东西能帮你在某次慌乱中把代码找回来，那它就是值的。数据无价，提交有痕，祝每一位开发者都能与 Git 和平共处。