空明流转第一次碰到误删的时候，我盯着终端里空荡荡的目录，脑子瞬间空白了十几秒。那是一个写了两天半的模块，七个文件，四千多行业务代码。起因很简单，我想整理目录结构，结果一条 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 --