空明流转第一次碰到误删的时候，我盯着终端里空荡荡的目录，脑子瞬间空白了十几秒。那是一个写了两天半的模块，七个文件，四千多行业务代码。起因很简单，我想整理目录结构，结果一条 rm 命令按错了路径，连个确认提示都没有。现在回头看，这段代码其实 30 秒内就能救回来，但当时我在“要不要推倒重写”的恐慌里至少浪费了十分钟。
后来我总结出一个特别朴素的结论：Git 误删这件事，真正可怕的不是代码消失了，而是你不知道 Git 已经把代码记在了哪里。只要代码进入过 Git 仓库——哪怕只是 git add 过一秒钟——Git 的对象库里大概率还留着它的快照。剩下的问题只有一个：你知不知道去哪里翻出来。
这篇文章就是冲着“30秒急救”这个场景来的。我会按误删发生后的实际操作顺序，把文件被删、reset 回退、分支删除、stash 丢失、clean 误伤这些常见事故一条条拆开，给你可以直接抄的恢复命令，也会告诉你哪些情况真的救不回来。文章后面带了一张急救速查表，建议收藏，关键时刻别指望脑子比终端快。
1. 误删之后先别慌，先搞清你手上是什么状态
很多人一发现代码没了，第一反应是拿起终端就开始敲命令。这点真的很要命。Git 恢复误删的原理其实很简单：从某个还保留着旧版本的快照里把内容捞回来。但如果你在捞之前先做了一堆不知道会不会影响仓库状态的操作，反而可能把唯一能救回来的机会给覆盖掉。
所以误删后的第一件事，不是恢复，是判断。
1.1 判断代码到底丢在哪个区域
Git 对文件的跟踪分三个区域：工作区、暂存区（index）和本地仓库（HEAD）。不同区域的丢失，恢复路径完全不一样。
举个最直白的例子。你正在写 login.py，辛辛苦苦改了两小时，还没 git add。这时候你在编辑器里 Ctrl+A 然后 Delete，保存了——这属于工作区的代码丢失。Git 确实在对象库里留有上一个 commit 版本的 login.py，但你这两小时的新改动如果从未被 Git 记录过，Git 是无论如何也找不回来的。这是第一个要认清的真相：Git 只能恢复它“见过”的内容。
所以收到误删通知之后，先回答自己三个问题：
- 文件是否被 Git 跟踪过（之前有没有
git add或commit）？ - 你丢的修改有没有进入过暂存区？
- 还是说你已经
commit过，只是后来被回退或删掉了？
这三个问题决定了下面你该走哪条恢复路线。
1.2 用一条 status 命令快速摸底
打开终端，先跑 git status，其他什么都别干。
code复制$ git status
On branch main
Changes not staged for commit:
deleted: login.py
如果输出里显示 deleted: login.py，恭喜你，这属于最轻量级的事故。文件本来就被 Git 跟踪着，你只是把工作区的副本删了，仓库里还保存着完整的版本记录。恢复它只需要一条命令，下文会讲。
如果输出里什么都没有，但你的代码确实不见了，那说明情况更复杂，可能是 reset --hard 把本地仓库指针整体往后拨了，也可能是整个分支被删了。这时候要去看 git reflog，这是第三章的内容。
记住一个判断口诀：只要 git status 里还能看到某个文件处于“已删除”状态，说明 Git 还在跟踪它，恢复就是秒级的事。真正麻烦的是 status 一片干净、但代码已经变成几天前版本的情况。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 工作区文件被删：30秒恢复，只靠一条命令
这是最典型、也最让人虚惊一场的场景。你上一周刚提交过代码，今天正改到一半，手一抖把整个文件删了。git status 显示 deleted，而你此刻唯一想做的事就是让它消失。
2.1 先用 restore，这是新版 Git 的默认答案
Git 2.23 之后引入了 git restore 命令，语义比老命令 checkout -- 清晰得多，专管“恢复”这件事。
bash复制git restore login.py
敲完回车，文件立刻从暂存区/HEAD 恢复到工作区，内容回到上一次提交时的样子。你的新改动如果还没提交，很遗憾，这部分不会回来——这是 GitHub 也好、命令行也好都无法跨越的物理限制。但总比整个文件连同上一次提交的版本一起丢掉强。
如果是整个目录被删，直接恢复目录：
bash复制git restore .
或者明确指定从某个历史版本恢复，比如从上一次 commit 强制拉回来：
bash复制git restore --source=HEAD --worktree login.py
--source=HEAD 是显式说明“从本地仓库最新的提交里取”，--worktree 指定只恢复工作区。这命令的阅读体验比 checkout 好得多，适合刚接触 Git 的同事。
2.2 老项目、老系统上，checkout 依然要会
有些旧项目还在用老版本的 Git，或者团队里有人习惯老语法。git checkout -- <file> 在很长一段时间里是唯一的标准答案，现在依然是完全可用的。
bash复制git checkout -- login.py
这个命令的意思和 git restore login.py 基本一致：从暂存区把文件内容拉回到工作区。如果你的文件没有被 git add 过新修改，那它就等价于从 HEAD 恢复。
我自己现在混用这两个命令。写新脚本时用 restore，进老服务器排查问题时还是习惯 checkout --。两个都记住没有坏处，万一哪台机器的 Git 版本太老，只有后者能救你。
2.3 如果你删的不是整个文件，而是某段代码
这个场景很多人没意识到：编辑器里 Ctrl+Z 失灵、不小心保存了删掉大段逻辑的版本，git status 可能只显示文件被修改，不显示“已删除”。这时候 git restore 会把整个文件回退到上次提交状态，那连之前正常的部分也一起丢了。
所以在执行恢复命令之前，先确认自己是“整个文件被删”还是“部分内容被误改”。如果是后者，优先看编辑器自带的本地历史：
- VS Code：右键文件，选择“打开时间线”，能翻到不同时段的自动保存快照。
- IntelliJ IDEA：右键文件，Local History -> Show History，能恢复任何一次更改。
- Vim/Neovim：如果你开了 undofile，
u可以撤销，甚至重启后也能撤销。
用编辑器自带历史的好处是只恢复那一段改动，不影响当前文件的其他内容。这类工具经常被忽视，但关键时刻比 Git 更实用——因为本地历史机制记录的是实时编辑状态，不是提交状态。
2.4 已暂存但未提交的文件被删，恢复方式稍有不同
假设你的流程是：改完代码 → git add 把文件放进了暂存区 → 还没 commit → 结果工作区文件被删了。这时候 git restore login.py 依然能恢复，但从暂存区拉回来的内容是最新 git add 的那一版，而不是磁盘上被删之前的状态。
如果只想恢复工作区、保留暂存区状态，用：
bash复制git restore --worktree login.py
如果想连暂存区的状态也一起恢复到 HEAD：
bash复制git restore --staged --worktree login.py
其实大多数日常场景下，一条不带参数的 git restore login.py 就够用了。刚被删的文件通常暂存区和 HEAD 内容一致，恢复结果没区别。但搞清楚 --staged 和 --worktree 的区别，能让你在更复杂的条件下不慌。
3. 已提交代码被reset或回退：reflog才是终极后悔药
第二种事故比文件删除更吓人：你的代码明明已经提交过了，结果因为 git reset --hard、git rebase 或者反复 commit --amend，分支指针被移到了别处，看起来所有提交都“消失”了。这时候很多人第一反应是放弃，觉得历史已经改写，回不去了。
其实 Git 的设计相当体贴。它不会在你执行 reset 的瞬间把旧提交物理删除，而是把这些提交对象标记为“不可达”——没有分支或标签引用它们，但对象仍然躺在对象数据库里。只要还没被垃圾回收机制清掉，就有办法把它们找回来。
3.1 reflog 记录着 HEAD 的每一次移动
git log 看的是当前分支的提交历史，而 git reflog 看的是 HEAD 指针本身的移动历史。哪怕你 reset --hard 回了三个版本之前，HEAD 曾经指向过新版本这一事实，会被完整记录在 reflog 里。
bash复制git reflog
输出长这样：
code复制e5a3f2c HEAD@{0}: reset: moving to HEAD~3
7b9d41a HEAD@{1}: commit: 完成支付模块
3bc4d91 HEAD@{2}: commit: 实现登录接口
看到 HEAD@{0} 之前的位置了吗？那行 7b9d41a commit: 完成支付模块 就是你回退前刚提交的东西。你只需要告诉 Git：“把我带回这个位置。”
3.2 最快恢复方法：用 reflog 定位后 reset 回去
假设你刚 reset --hard 误删了一堆提交，想直接撤销这次 reset：
bash复制git reset --hard HEAD@{1}
这条命令的意思是：让当前分支回到 HEAD 上一次所在的位置。执行完再看 git log，所有“消失”的提交全回来了。
如果回退之前的提交距离现在已经有一段距离，或者你想恢复的是更早的某个提交，可以直接用 SHA：
bash复制git reset --hard 7b9d41a
这里有个细节要注意：HEAD@{1} 是相对位置，如果你在 reset 之后又做了几次 commit、checkout，编号会变；而 SHA 是绝对位置，只要你还记得或能从 reflog 里翻到，它就不会变。所以我的习惯是，一旦在 reflog 里看到目标提交，立刻把 SHA 复制下来，再用 SHA 操作，避免中途多做几个操作导致相对编号错位。
3.3 分支被删了怎么办：reflog 加 branch 命令双保险
删分支比 reset 更让人崩溃，因为 git branch -D 删掉分支后，分支名和引用都消失了。但提交对象一样还在对象库里。恢复方法分两步。
第一步，查 reflog，找到那个被删分支最后指向的提交：
bash复制git reflog
输出里可能混杂着各种 checkout 和 commit 记录，重点找被删分支最后一次 commit 的 SHA。
第二步，用这个 SHA 重新创建分支：
bash复制git branch recover-branch 7b9d41a
或者直接检出并创建新分支：
bash复制git checkout -b recover-branch 7b9d41a
这一步执行完，被删分支上的代码就全部回来了。recover-branch 这个名字随意起，恢复之后建议先推送到远程，作为双保险。
3.4 reflog 的时间窗口：为什么说“尽快”是铁律
reflog 不是永久有效的。Git 默认的 reflog 过期时间是 90 天，也就是说，超过 90 天的 HEAD 移动记录会被清理。另外，如果你手动执行了 git gc --prune=now，那不管多新的不可达对象都可能被立即物理删除，连 fsck 都救不回来。
所以误删之后记住两件事：第一，立刻停止往仓库里塞大命令，尤其是 git gc、git prune、git repack 这类清理操作；第二，尽早执行恢复，越早越好，30 秒能解决的事不要拖到 30 天后。
4. 高阶事故现场：丢失的stash、误伤的clean和不可达对象
前面的场景至少目标明确，都是“有文件被删，有版本被回退”。但还有一类事故更阴间——你甚至不知道代码丢哪了，只能在对象数据库里大海捞针。这一节我分享两个我真实踩过的坑，以及完整的排查链路。
4.1 误删 stash 之后，fsck 是怎么帮我捞回来的
有次我在赶项目，临时把一批改动 git stash 存起来，然后想清理一下 stash 列表。大概是因为界面太顺手，我执行了 git stash clear，把好几个 stash 一股脑全清了。反应过来的时候，心里只有一个念头：完了。
git stash list 已经空无一物，但我知道 stash 在底层其实就是一种特殊的 commit，对象库里肯定还留着。排查链路如下：
第一步，先看看仓库里有哪些不被任何引用指向的悬挂对象：
bash复制git fsck --lost-found
git fsck --unreachable
输出里会有一堆 dangling commit。这些 commit 没有分支、没有标签，也没有 reflog 引用，但它们的内容都还在。
第二步，逐个查看这些 commit 是不是我要找的 stash：
bash复制git show <SHA>
git show 会把 commit 的改动内容打印出来。看到熟悉的文件名和代码片段时，基本就能确认这就是我误删的 stash。
第三步，把确认后的 commit 恢复到工作区：
bash复制git stash apply <SHA>
那条命令执行完，原本以为永远丢掉的工作区改动全部原样回来了，包括未提交的文件和暂存状态。整个过程大概五分钟，如果当时我懂 fsck，能再压缩一半时间。
4.2 git clean 误删未跟踪文件：能救与不能救的边界
git clean -fd 是清理仓库垃圾文件的神器，但它也是误删事故的头号元凶之一。它会把工作目录下所有未被 Git 跟踪的文件和目录直接删掉，比如你的 .env、node_modules 里未跟踪的配置、或者某个刚从网上下载还没 git add 的压缩包。
关于这种事情，我必须诚实地说：如果那个文件从出生起就没被 Git 记录过，Git 这边没有它的任何快照，reflog 和 fsck 都派不上用场。你能走的只有操作系统层面的恢复方案，比如 macOS 的 Time Machine、Windows 的文件历史记录，或者第三方数据恢复软件。
但有一个容易被忽略的例外：如果这个文件之前被 git add 过，后来又因为某种原因变成了未跟踪状态，那它的对象可能还残留在对象数据库里，用 git fsck --unreachable 有可能找到——尽管这种操作的成功率取决于它是否已经被 GC。
4.3 强制 GC 后的最后挣扎：对象还在不在
如果你真的手滑执行了 git gc --prune=now，理论上不可达对象会被物理删除。但现实世界总有意外，有些对象可能因为还有别的引用而幸存。此时可以尝试：
bash复制git fsck --full --no-reflogs --unreachable
这个组合会强制扫描所有不受 reflog 保护的对象。如果连它都输出为空，那基本可以确定数据已经从 Git 侧彻底消失，别在命令行上继续耗时间，早点换文件恢复工具更实际。
这条经验背后是血的教训：git clean 和 git gc 是误删事故里最凶的两个命令，执行前务必看清楚 -n 参数。
git clean -fdn 可以提前预览会被删除的文件清单，确认无误后再去掉 -n 真正执行。这个习惯我建议谁都别省。
5. 让误删变为小事故：提交习惯与急救速查表
讲完那么多恢复方案，说句掏心窝的话：真正的高手不是恢复得快，而是根本不给自己制造误删事故的机会。这几年的经验让我养成了几个看起来不起眼、但性价比极高的习惯。
5.1 小步提交，把“后悔药”的时间窗拉长
以前我总想着“写完一个完整功能再 commit”，结果有一次连续写了一个小时，中间没提交任何东西，最后手一抖把文件删了。那一刻我真的体会到了什么叫“叫天天不应”。
后来我改成每完成一个小阶段就 git commit 一次。比如：写了个工具函数，提交；调通了接口，提交；修完一个 bug，提交。每次提交内容不用多，但要让本地仓库里始终保存着最近几次可回退的版本。这样即使误删，最多丢最近半小时的改动，而不是一整天的劳动成果。
5.2 定期推送远程，让备份离开本地硬盘
本地仓库再可靠，也扛不住硬盘损坏、电脑被盗这类极端情况。我现在每完成一个阶段就 git push 一次。远程仓库不仅要推，还要推得有规律。这样就算本地的 .git 目录整个坏了，还能从远程把代码拉回来。
如果你是单人项目，可以给自己建一个 backup 分支，专门用来定期推送快照，日常开发在 main 分支上继续。这是零成本的心理保险，强烈推荐。
5.3 配置几个 alias，降低手滑概率
有些误删纯粹是因为命令太长、输入太急导致敲错。我给自己配了几个常用 alias，同时减少拼写错误：
bash复制git config --global alias.gs "status"
git config --global alias.s "restore"
git config --global alias.lg "log --oneline --graph"
当然，alias 不能完全阻止误删，但它能把高频命令缩短到容易记忆的长度，特别是在终端里要尽快执行恢复时，少打几个字符，就少一点出错的概率。
5.4 急救速查表：30秒内快速定位恢复命令
最后落实到你最关心的“30秒”上。我把所有场景整理成了一张速查表，建议复制粘贴到自己的笔记工具里。
| 误删场景 | 优先操作 | 风险提示 |
|---|---|---|
| 工作区文件被删，未提交过 | 编辑器本地历史恢复，Git 无法救 | 从未进过 Git 的内容救不了 |
| 工作区文件被删，已跟踪 | git restore <file> 或 git checkout -- <file> |
未提交的新改动会丢 |
| 文件已 add，未 commit | git restore --worktree <file> |
恢复的是暂存区版本 |
| reset --hard 后回退错误 | git reflog 找 SHA，再 git reset --hard <SHA> |
尽快做，避免被 GC |
| 分支被删 | git reflog 找 SHA，再 git branch <新名> <SHA> |
分支名会恢复，对象还在 |
| stash 被 clear | git fsck --lost-found 找 SHA，再 git stash apply <SHA> |
依赖未被 GC 清理 |
| clean -fd 误删未跟踪文件 | 文件恢复软件 / 系统快照 | 如果从未 add 过，Git 侧几乎无法恢复 |
| amend 后想找回旧提交 | git reflog 找 amend 前的 SHA，git reset --hard <SHA> |
会丢掉 amend 后的提交 |
这张表不是万能的，但它覆盖了我这几年遇到过的绝大多数误删场景。在你最慌的那 30 秒里，先看表、再动手，远比满脑子胡思乱想管用。
我个人在实际操作中的体会是，git reflog 和 git fsck 是每个用 Git 的人最该提前了解的两条命令，它们未必天天用，但一旦用上，省下的可能就是一整天的重写工作。趁还没出事，开个终端把这两条命令跑一遍，看看输出里都有什么，练练手。真出事那天，你一定会感谢现在这个多花两分钟的自己。