Git误操作之后的抢救，其实没有想象中那么玄乎。说句得罪人的话，我见过太多被误操作搞得焦头烂额的人，最后不是栽在操作上，而是栽在慌乱上——一边在网上疯狂搜命令，一边在目录里东敲一下西敲一下，结果把本来还能救的提交彻底弄丢了。这篇急救手册要解决的就是这个问题：把误操作后的抢救流程做成一张"先做什么、再做什么"的动作清单，并且给出真正常用、短到可以记进肌肉记忆的速救命令。我会把原理讲清楚，为什么能救、怎么救、边界在哪。适合所有正在用Git、但是遇到事故会慌的开发者，也适合刚入门想建立安全感的同学。
1. 先别慌：Git急救的第一原则是止损，不是炫技
1.1 先搞懂一个底层事实：Git的误操作大多数其实不可怕
Git本质上是一个内容寻址的对象数据库。你平时看到的main分支、HEAD、暂存区，统统只是"指向某个commit的指针"。而一个commit一旦被创建出来，它里面装的内容（文件快照、作者信息、父提交关系）就被冻结在对象库里，不会因为分支指针的移动而消失。只有一种情况它会被真正删除——被垃圾回收机制(gc)在特定条件下清理掉。
用储藏室打比方：commit是打包好的纸箱，分支名是贴在纸箱上的标签，HEAD是"我正站在哪个箱子前面"的手势。reset只是从箱子A挪到箱子B，并把A上面的标签撕下来。被撕掉标签的箱子还在仓库角落，你去翻登记簿（reflog）就能找到它。这就是为什么误reset、误提交、误删分支、误merge之后，绝大多数情况数据并没有真正消失，只是"指针不指向它们了"。急救的本质就一句话：把标签贴回去。
明白了这个底层逻辑，你就知道急救其实很"温和"——不是凭空找回数据，而是重新建立引用。真正要小心的不是已经发生的误操作，而是在慌乱中继续执行的下一个破坏性命令。
1.2 急救三戒：先拍照，再动手
误操作发生后，人很容易陷入"快点补救"的冲动。但越是这种时候，越要执行下面三戒。
第一戒：不追加破坏。慌的时候最忌讳立刻执行下一个不确定后果的命令。尤其是git clean、git reset --hard、git checkout -- .这种带"清空"性质的命令，每多执行一次，都可能把你唯一的希望（某个还没有被引用的commit）推向真正的丢失。
第二戒：先拍照留底。把git status、git log --oneline、git reflog三条只读命令的输出截图保存下来。这三张"病历"能帮你判断损失范围，也防止你后续操作把现场进一步弄乱。如果磁盘空间允许，直接把整个项目目录复制一份（包含.git目录），这是最笨但最稳的保险单。几百MB在硬盘上不算什么，别心疼。
第三戒：只读优先。git status、git log、git reflog、git fsck都是只读的，随便跑，跑多少遍都不会出事。git reset、git checkout --、git clean这类写操作，必须在确认目标之后再进行。急救中的多数失误，都是因为在信息不足时就动了写操作。
2. 本地未推送事故：从误commit到误删文件的逐级抢救
2.1 提交错了还不至于重写代码：--soft与--mixed怎么选
先记住一个事实：在代码还没有push到远端的情况下，你干的任何"提交事故"都不值得惊慌，因为历史还没有被公开。你唯一需要选对的是reset的模式。
| 模式 | 提交指针回退 | 暂存区 | 工作区 | 典型场景 |
|---|---|---|---|---|
git reset --soft HEAD~1 | 是 | 保留改动且保持已暂存 | 不变 | 提交消息写错了想改；提交后发现忘了加文件 |
git reset --mixed HEAD~1（默认） | 是 | 保留改动但取消暂存 | 不变 | 提交后发现选错了文件集，想重新组织 |
git reset --hard HEAD~1 | 是 | 清空 | 还原到目标提交 | 确定这次提交的内容完全不要 |
最常用的场景是：提交完发现里面藏了不该提交的东西（比如调试日志、密钥、临时文件），而且还没push。流程很简单：
git reset --soft HEAD~1 # 23个字符，退回提交，改动保留为已暂存 # 处理掉不该提交的文件 git add 真正要提交的文件 git commit -m "修正后的提交说明"如果只是想改最近一次提交的说明文字，用git commit --amend -m "新消息"就能搞定，命令本身加消息大概26个字符。但注意amend只适合还没push的情况，一旦推出去，后面的同事会莫名收到一个内容一样但哈希完全不同的提交，这种"历史改写"在团队协作里是大忌。
这里有个我经常在代码评审里强调的细节：--soft和--mixed都能保留文件改动，区别只在暂存区状态。拿不准的时候选--mixed（即不写模式参数，直接git reset HEAD~1），因为"回到手选文件重新提交"的容错空间最大，改动都躺在工作区里等着你重新决定。
2.2 误删文件怎么救：关键在于删除发生在哪个阶段
误删文件是另一个高频事故，但很多人会漏判一个重要变量——那个文件当时处于什么状态。我见过不少人在文件已经被git add进暂存区之后，又敲了git restore .，然后惊慌失措以为文件没了。实际上不同状态下急救命令完全不同。
- 工作区里改了但还没提交，直接删掉了：
git restore 文件名。因为文件在HEAD和暂存区里都有完整内容，这条命令只是把工作区还原回去。 - 已经
git add过、暂存区里有快照，然后删了：同样是git restore 文件名。 - 已经提交过，但删除动作本身也被暂存了（典型是执行过
git rm）：这时git restore 文件名会报错，因为暂存区里记录的也是"已删除"。要用git checkout HEAD -- 文件名，从HEAD提交节点同时还原暂存区和工作区。 - 整个分支刚被
git reset --hard打回原形，文件在之前的提交里：恭喜你，这已经升级成"要翻reflog"的级别，直接跳到第四章。
git restore是Git 2.23之后推出的命令，语义比老式的checkout --更清晰。老版本仓库用git checkout -- 文件名等效，效果一样。我还提醒一句：删除前的文件如果从未被Git跟踪过（untracked且从未add），上面所有命令都救不了它，这时只能靠编辑器的本地历史或文件系统的回收站。
2.3 提交到了错误分支：一个手术式的三步解法
场景很常见：在main分支上加班修bug，改完习惯性git add . && git commit -m "修复问题"，抬头一看，提交落在main上了，可这活儿应该在feature分支上做。下面这套流程是我在团队里讲过很多遍的标准手术：
# 第一步：在当前位置先建一个分支，把"误提交"保护起来 git branch feature # 第二步：把main指针拉回原位（确保工作区干净，不干净就先stash） git reset --hard HEAD~1 # 第三步：切到feature分支继续干活 git checkout feature第一步是最关键的。git branch feature本质上是在给你误操作产生的commit"贴标签"，把它从"随时可能被gc收走的悬挂对象"变成一个有名字、有引用的分支。做完这一步，后面哪怕reset写错了SHA，原始提交都不会丢。如果工作区还有未提交的改动，reset --hard会一起清掉，这时候改用软重置路线：
git reset --soft HEAD~1 # 撤回提交，改动保留为暂存 git stash # 临时存放改动 git checkout feature git stash pop # 取回改动 git add . git commit -m "移动到正确分支的提交"两条路线结果一样，区别就在你当时工作区脏不脏。这类事故全程没有碰过远端，所以不需要担心其他同事受影响。
3. 已经推到远程的事故：改历史是下策，revert才是上策
3.1 为什么远程分支上的误提交，绝对不能reset+force
未push的提交随便折腾，但一旦commit推到了公共远程分支，事情的性质就变了。还拿储藏室比喻：本地reset是撕自己仓库的标签，而push到远程后，这个commit已经变成"公共书架"上其他人都能拿到的书。你以为自己悄悄把书撤回来就完事，可队友A已经翻过这本书了，队友B甚至在里面做了批注。
一个典型的翻车现场是：A把含敏感信息的commit推到main，然后执行git reset --hard + git push --force强行删掉。提交确实从远程消失了，但B之前已经pull过，B的本地分支仍然保留着这个commit。下次B推代码时，Git会发现双方历史分叉，要么爆冲突，要么B一个不小心又把那个commit带回去，形成"僵尸提交"循环。
正确的做法是git revert——它不动旧提交，只是在它后面追加一个反向的提交，把改动抵消掉：
git revert HEAD # 撤销当前分支最新一次的提交，13个字符 git revert a1b2c3d # 撤销指定哈希的提交队友们pull的时候，看到的只是一个正常的、新的提交，历史是线性的，不需要任何force操作，没人会因此产生冲突或丢失内容。Revert的安全性是它以"多一次提交"为代价换来的，但这代价在公共分支上完全值得。
另一个实用技巧：revert可以加--no-commit参数，先只做改动不生成提交，让你在提交前检查一下撤销结果是否正确。如果revert之后又后悔了，想恢复原提交的代码，那就再revert一次刚才的revert，一层层抵消。
3.2 合并错了还想翻盘：merge中、merge后、以及merge已推送
误合并的急救要分三个阶段看，处理方式完全不同。
合并过程中遇到一堆冲突，改来改去觉得不如放弃：git merge --abort，17个字符，直接回到merge开始之前的状态，包括冲突产生的临时改动一起清掉。注意它只对"正在进行的合并"有效。
合并已经完成了，但没push，觉得合并得不对：git reset --hard ORIG_HEAD。这里的关键是理解ORIG_HEAD——Git在执行merge、rebase、reset、cherry-pick这些危险操作之前，会自动把当前位置记录到ORIG_HEAD这个临时标签里。所以"回到ORIG_HEAD"就是回到这次危险操作之前，等于什么都没发生过。这是本地事故里性价比最高的急救命令，才26个字符。
合并已经push出去了，这个最麻烦。普通revert处理不了合并提交，因为合并提交有多个父节点，Git不知道要撤销到哪边。必须用-m参数指定要保留的主线：
git revert -m 1 <合并提交的哈希>-m 1的意思是保留第一个父节点（也就是你合并时所在的主分支），撤销merge带入的所有改动。如果不带这个参数，Git会直接报错拒绝执行。这一步做完，历史里会留下三个提交：原合并、revert合并。因为revert的也是一个普通提交，如果后续又想重新合并那个分支，直接再revert掉这次revert即可。
还有一个容易被忽略的点：ORIG_HEAD只会记住最近一次危险操作的起点。如果你在merge之后又做了一次reset，ORIG_HEAD就被覆盖了。所以这类急救要趁早，或者一开始就把ORIG_HEAD对应的哈希人工记下来。
3.3 rebase和cherry-pick翻车自救
rebase在冲突中想退出：git rebase --abort，19个字符。它会把工作区、暂存区、HEAD全部恢复到rebase开始之前的模样，哪怕你已经手动解决了一半冲突，也会一并还原。这个命令的存在就是"rebase全程可中断"的底气。
rebase已经跑完，但结果一塌糊涂（典型的例如把几百个提交压缩错、提交顺序全乱了）：如果确定再没有后续提交，git reset --hard ORIG_HEAD能回到rebase前的位置。但如果你rebase之后又往上叠了几个新提交，这个命令会把后续提交一起丢掉，风险就大了。更稳妥的做法是打开git reflog，找到rebase之前的那条HEAD记录，用分支标签把它保护起来（第四章细讲），再决定怎么合并回来。
cherry-pick的处理逻辑一样：冲突中退出用git cherry-pick --abort，完成后后悔用revert或reset ORIG_HEAD。还有git pull --rebase翻车，本质也是rebase事故，同样按rebase的急救流程处理——git rebase --abort直接把这次pull还原到开跑前的状态。
4. reflog是真正的时光机：丢失commit的高级救援
4.1 reflog原理与有效期：为什么删掉的东西还在
前面说的本地事故、误reset、误删分支，大多用reflog就能解决。reflog（reference log）记录的是仓库里所有引用——分支、HEAD——每一次移动的流水账。commit、reset、merge、rebase、cherry-pick、checkout都会产生一行记录。
它有几个特点让它在急救里价值极高：一是它是本地的，不会因为你不push而丢失；二是它记录的是"操作前的状态"，天然是回溯的入口；三是有明确的保留期。默认情况下，可达对象在reflog里留90天，不可达对象留30天。而gc在清理不可达对象时，默认只清两周以前的。换算成人话就是：你误操作后，大约有两周到三个月的窗口期来救援，之后对象才可能真正被清掉。
用git reflog看输出，每行最左边是操作完成后的SHA，中间是HEAD@{序号}，行尾是操作说明：
f4a1b2c HEAD@{0}: reset: moving to f4a1b2c 3e8d111 HEAD@{1}: commit: 修复用户登录超时问题 7c2d9e0 HEAD@{2}: commit: 增加订单导出功能 2b8ae44 HEAD@{3}: checkout: moving from main to feature急救时你要找的是"事故节点之前那行"——比如上面对应"误reset之后，我想找回feature上最后那个提交"，答案就是HEAD@{1}那行的3e8d111。
4.2 误reset --hard后找回丢失工作：完整操作规程
来一个完整案例。某开发者在feature分支干了三天，想临时回退到merge前的main去验证一个旧行为，结果手一抖把命令敲成了git reset --hard main。本来好好的工作区瞬间回到main的状态，三天的工作看起来全没了。这时候按我的操作链路走。
第一步，git status确认损失范围，也确认一下当前HEAD到底停在哪个提交。
第二步，git reflog --date=relative，翻到reset操作之前那几行。重点找"commit: 完成XX功能"这类提交说明，它对应的SHA就是丢失工作的最新提交。
第三步，给找到的SHA贴标签保护，而不是急着reset回去：
git branch rescue 3e8d111这一步是整个流程里我最想强调的。用git branch新建标签是"只做加法"的安全动作，它不动HEAD、不碰工作区、不改变任何现有状态，万一SHA敲错了也没有任何损失。相比之下，如果你直接git reset --hard 3e8d111，万一SHA记错，原始引用又被覆盖一次，急救就成二次事故了。
第四步，git log --oneline rescue核对提交内容，确认三天的工作确实完整。
第五步，确认无误后再决定怎么融合：可以直接切到rescue继续干活，也可以先git checkout feature再把rescue合并进来，或者git branch -f feature rescue把feature指针强行移动到救援分支的位置。我通常选择切过去验证编译通过、测试跑绿之后，再删掉临时标签。
救援期间还有个大忌：不要执行git gc或git prune。这两个命令是垃圾回收的主力，一旦跑起来，那些无人引用的对象会被成批清掉，相当于把急救室的门焊死。
4.3 连reflog都失效的终极手段：fsck捞dangling对象
reflog也有覆盖不到的时候：仓库很老、reflog已被清理，或者某些对象（比如丢失的stash）从没被分支引用过。这时候用git fsck --lost-found，24个字符，把对象库里所有"没有引用指向"的提交、文件快照全部列出来。
git fsck --lost-found输出里会出现类似这样的行：
dangling commit 8b2f3d0a1c9... dangling blob a1b2c3d4e5...dangling commit就是没有任何分支、标签指向的提交，这正是你要打捞的对象。先用git show 8b2f3d0a1c9...查看它里面的文件快照和提交说明，确认没问题就git branch rescue 8b2f3d0a1c9...把它保护起来，后续处理同上一节。如果想找更彻底的孤儿对象，可以加参数git fsck --full --no-reflogs --unreachable，连reflog里出现过但已不可达的对象也一并捞出来。
git stash drop之后才想起里面还有重要改动，也是走这条路。丢掉的stash在fsck里会显示成一个特殊的dangling commit，找到后可以直接git stash apply <SHA>尝试恢复；如果Git提示结构不匹配，就退回通用方案——git show确认内容，然后从那个提交里把文件取出来。
5. 三十字速记卡：贴显示器旁边的急救命令
5.1 速记卡总表：每条命令都控制在30个字符内
这个"30字"不是我随便说的噱头。我把空格也计入字符，路径、文件名、哈希这些占位符不计，下面这张表里的每一条急救命令，用的时候都正好在30个字符以内，是可以抄在小纸条上贴到显示器边框的。
| 事故场景 | 速救命令 | 字符数 | 适用条件 |
|---|---|---|---|
| 最近一次提交信息写错了 | git commit --amend -m "新消息" | 26 | 未推送 |
| 提交完后悔，保留改动退回 | git reset --soft HEAD~1 | 23 | 未推送 |
| 提交完后悔，同时取消暂存 | git reset HEAD~1 | 17 | 未推送 |
| 确定最近提交内容全不要 | git reset --hard HEAD~1 | 25 | 未推送 |
| 误删工作区文件 | git restore 文件名 | 15 | 文件已暂存或已提交 |
| 误删且删除动作被暂存 | git checkout HEAD -- 文件名 | 27 | 文件已在仓库 |
| 刚add错文件想撤出暂存 | git restore --staged 文件名 | 28 | add错了但没提交 |
| 已推送的误提交要撤销 | git revert HEAD | 13 | 已推送 |
| 撤销已推送的合并提交 | git revert -m 1 哈希 | 18 | 已推送 |
| 放弃进行中的冲突合并 | git merge --abort | 17 | 合并冲突中 |
| 放弃进行中的rebase | git rebase --abort | 19 | rebase冲突中 |
| 回到最近一次危险操作前 | git reset --hard ORIG_HEAD | 26 | 紧急且无后续提交 |
| 查看所有历史位置 | git reflog | 10 | 随时可用 |
| 给救援目标提交贴标签 | git branch 新分支 哈希 | 20 | 已确认SHA |
| 打捞无引用的孤儿提交 | git fsck --lost-found | 24 | reflog已过期 |
如果你只能记住一句话，那就是：撤销提交用reset，远程回滚用revert，操作翻车找ORIG_HEAD，提交走丢找reflog。这一句刚好30个字，就是整张卡片的浓缩版。
5.2 平时就把安全弦绷上：让事故少发生
急救再好，也不如少出事。我把这几年踩出来的防御习惯列出来，每一条的执行成本都很低，但收益极大。
第一，git clean永远先加-n预览。git clean -n列出将要删除的untracked文件，确认没问题再执行git clean -f。没有预览的clean就是在枪毙untracked文件，Git帮不了你。
第二，强推用git push --force-with-lease而不是git push --force。前者会先检查远程分支状态是否和你本地看到的一致，如果不一致（说明有队友推了新提交）就直接拒绝，相当于一个防呆开关。我见过太多团队的事故是从不带lease的force开始的。
第三，大动作前贴标签。合大分支、改历史、跑rebase之前，花一秒钟git tag backup-日期或者git branch backup。这个动作成本低到可以忽略，但它保证你随时有一条物理意义上的退路。
第四，git add -p分块提交，逼自己看一眼每个改动块再决定是否暂存。无脑git add .是大量"误提交"的源头，分块提交虽然慢一点，但能挡掉绝大多数不该进仓库的内容。
第五，把常用救援命令做成别名。比如：
git config --global alias.undo 'reset --soft HEAD~1'之后git undo只要7个字符，这就是"三十字速救"的终极形态——短到刻进肌肉记忆，慌乱里也能盲打出来。还可以配git reflog、git abort = merge --abort这类别名，顺手就记。
第六，开启rerere。git config --global rerere.enabled true会让Git记住你解决过的合并冲突模式，下次遇到相同冲突时自动使用之前的解决方式。它没法救你一次事故，但能长期减少你在合并/rebase里消耗的时间和情绪，属于防御配置里性价比最高的一条。
5.3 说句实话：哪些误操作是真的救不回来
急救手册也得写清楚"不治之症"，省得你抱着错误期望耗时间。
从未被Git跟踪过的文件，比如新建了但没add过、没commit过的临时文件，误删之后Git的reflog、fsck都帮不上忙。因为整个对象库里就没有它的快照，Git从未"认识"它。这种情况只能靠编辑器本地历史、文件系统回收站或整目录备份。
已经被git gc或git prune亲手清理掉的对象，同样救不回。这里要特别注意：有些教程会教"定期跑gc瘦身"，如果仓库里还有你可能需要的误操作遗留对象，gc跑完就等于宣判死刑。所以急救期间我坚决不碰gc。
远端分支被删除、本地又没拉取过，同时没有别人clone过这份数据：基本无解。数据只要从未到过你本地，本地工具就无从谈起。唯一的机会是多数Git服务商在网页端提供分支恢复入口，但那属于服务商层面的能力，和本地命令无关。
对应的行动建议是：遇到以上情况，别在Git命令里耗太久，立刻转去翻IDE的Local History、编辑器的自动保存文件，或者问问队友那边有没有副本。抓救命稻草也有优先级，Git不是唯一的稻草，但一定是最先该试的那根。
最后说点个人体会。我带过的团队里，犯过最多错误的不是新人，反而是自认为很熟Git的老司机——因为他们做危险操作时从不刹车。这几年我养成了一个小习惯：每次执行reset、rebase、force push这类命令之前，先在心里问自己一句"如果这一步错了，我怎么回来"。这个问题的答案通常是reflog，但如果答不上来，就先贴个标签再动手。急救的本质不是让你记住多少条命令，而是让你始终给自己留一条明确的后路。把这张三十字速记卡贴好，把git undo配置好，哪怕哪天深夜真的手滑了，你也能一边深呼吸一边把问题收掉。
