子月二二有一次，组里一个实习生态度特别好，git操作却把整个feature分支弄丢了：他以为先 git checkout dev 切走再回来就行，结果为了“清干净本地”，一条 git reset --hard origin/dev 把两天在本地写的东西全冲走了。当时整层楼都能听到他的哀嚎。
后来我帮他做了三件事：先让他别慌，再让他打开终端跑 git reflog，最后从一条悬空的提交记录里把分支完整捞了回来。整个过程不超过五分钟，代码一行没少。
这篇就是想把这种“急救能力”真正写透。既有新手装好Git之后第一步该配置什么、哪些命令会留下“后悔药”这样的保命常识，也有分支被删、提交被覆盖、push推错远端这类老手也会翻车的事故怎么低成本还原。你可以把它当成一张 Git 事故急诊表，收藏起来，下次遇到问题直接对号入座。
1. 先做心理建设：为什么你丢掉的提交，八成还能找回来
很多人一听说 commit 历史被覆盖、分支被删除，第一反应是“完了，代码没了”。实际上Git在设计上比大多数人想象中“抗造”。理解清楚它的存储模型，你就能在事故发生时不慌不忙地判断：这事能救，并且大概率能救回来。
1.1 Git 的底层是“追加日志”，不是“覆盖数据库”
你在一个仓库里看到的 master、feature/login 这些分支名，本质上只是一个个“指针文件”，指向某个 commit 的哈希。真正存代码的是 .git/objects 目录里的对象数据库，commit、tree、blob 都是新增文件，写进去之后基本不被修改。
你可以这样理解：分支名像书签，Git 数据库像图书馆。你把书签从某页撕掉，不代表那页书被烧了。只要没做深度清理，commit 对象仍然安安静静躺在数据库里，等待某个引用或者 fsck 工具重新发现它。
所以，本地提交被“丢掉”的绝大多数场景，恢复策略都是同一个套路：找到那个 commit 的真实哈希，然后把某个分支或者 HEAD 重新指过去。
1.2 误删现场，先别急着“补刀”
急救的第一原则是：在不确定恢复路径前，停止一切可能扩大伤害的操作。
下面这些命令在事故发生后要特别谨慎：
| 操作 | 危险程度 | 原因 |
|---|---|---|
git reset --hard <某个commit> |
高 | 会覆盖工作区和暂存区，未提交内容可能蒸发 |
git branch -D <分支名> |
中 | 删除分支引用，commit 需要靠哈希找回 |
git clean -fd |
极高 | 未跟踪文件不在 Git 对象库里，基本救不回来 |
git gc / git prune |
极高 | 会真正清理悬空对象，把“还能救”变成“没救了” |
我自己踩过最痛的一次是误删分支后手贱执行了 git gc，结果悬空对象被清掉，只能靠着另一个开发机器上的副本把代码拼回来。所以当你发现误操作，第一件事是打开一个新的终端窗口，先跑只读命令查看现场，不要继续在当前仓库里做任何写操作。
1.3 认清三个“区”，你就懂了一半撤销命令
要理解 Git 的误操作恢复，首先得说清楚 Git 日常操作的三个区域：
- 工作区：你正在编辑器里看到的文件。
- 暂存区（Index）：通过
git add把文件的快照先放进去的地方。 - 版本库：
git commit后真正生成提交历史的地方。
很多撤销命令的本质，就是判断“我要把哪个区域的内容，覆盖到哪个区域”。
比如 git restore --staged <file> 是“把暂存区恢复成和版本库一致”，git restore <file> 是“把工作区恢复成和暂存区一致”。这个心智模型一旦建立，你看到命令就不会再靠死记硬背了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 新手高频翻车场景：add 错、commit 错、reset 过头怎么救
新手阶段最容易出事故的操作，其实就那么几个：把所有文件一股脑 git add .，提交完发现忘了加某个文件，或者刚提交就后悔想撤销。
2.1 不小心 add 了不该提交的文件
很多人的第一反应是用 git rm --cached 去删，这是把问题搞复杂了。正确做法分两步：
bash复制# 把文件从暂存区移出，但保留在工作区
git restore --staged <file>
# 老版本 Git（2.23 以前）用这条
git reset HEAD <file>
如果你已经提交了，并且之前忘了在 .gitignore 里排除掉某个本地文件，真正要处理的是让 Git 不再跟踪这个文件：
bash复制git rm --cached <file>
echo "<file>" >> .gitignore
git commit -m "chore: stop tracking file"
这里 --cached 的作用是只从版本库里移除，不会碰你本地磁盘上的文件。去掉跟踪关系之后再补 .gitignore，是避免同一个文件反反复复被误提交的根源解法。
2.2 刚 commit 完就想改：amend 的正确打开方式
最常见的情况是提交信息写错了，或者提交完发现漏了一个小文件。这时候如果提交还没 push 出去，git commit --amend 就是最优雅的后悔药：
bash复制# 修改上一次提交的说明文字
git commit --amend -m "feat: correct message"
# 想把漏掉的文件塞进上一次提交
git add forgotten.txt
git commit --amend --no-edit
注意 --no-edit 表示沿用上一次的提交信息，不用重新编辑器。当你在飞快地写代码时，这个参数能省下不少回车时间。
但要记住一个红线：只要这个提交已经 push 到公共分支、并且可能被其他人拉取过，就不要用 amend。因为 amend 本质是删除原提交、生成一个新提交，哈希已经变了。别人基于旧提交继续开发，你这边强行 amend 再强推，必然造成历史分叉。
2.3 提交完成后想撤销，soft/mixed/hard 怎么选
git reset 的参数是新手最容易混淆的地方。我给团队培训时常用一个类比：--soft 像只把日历翻回去，--mixed 是把台面上的东西收拾到抽屉里，--hard 是直接把屋子恢复到装修前的样子，桌子上没归档的文件也不见了。
| 参数 | HEAD 移动 | 暂存区 | 工