1. 误操作后的黄金60秒：先搞懂Git把自己藏在哪里

Git误操作这件事，我这些年处理太多次了。每次看到有开发者慌慌张张跑过来，说“代码没了”“分支删了”“提交不见了”，我第一句问的都是：你刚才做了什么，以及有没有看到一串hash。大多数时候，对方答不上来，但其实只要还能打开终端，就已经还有救。Git不像普通文件删除那样，删了文件系统就清空；它更像一张带撤销功能的时间账本，只是很多人在慌乱中根本不知道往哪一页翻。

这篇要聊的，就是一套我反复用过的Git急救方案。它覆盖工作区被覆盖、提交信息写错、merge和rebase中途反悔、分支误删、stash清空，还有远程分支被强推覆盖这几个高频翻车场景。每一条都会尽量压缩到30秒内给出命令和原理，适合刚接触Git的新手，也适合整天在命令行里打滚的老手。你不需要把Git的每个对象模型背下来，只需要在误操作后知道先别慌、再查reflog、最后动手。

1.1 除了工作区，Git还有一层“时间账本”

很多人在解释Git时，最喜欢说它有三个区：工作区、暂存区、本地仓库。工作区就是你能看到和编辑的目录，暂存区是提交前的缓冲地带，本地仓库里则保存着每一次提交的完整快照。这三个区在正常开发中只是用来描述不同状态，但在急救场景里，它们背后还有一个更容易被忽略的东西——对象仓库。每一次commit、每一次stash、每一次被重置掉的分支，在对象仓库里都会留下一个独立的Git对象，除非触发垃圾回收，否则它不会自动消失。

给这个“时间账本”一个更贴切的名字：reflog。它记录的是HEAD引用的历史，也就是Git的各个分支、HEAD指针在过去一段时间里所有移动过的位置。Git默认会保留这些日志大约90天。在这90天里，无论你是误删分支、reset掉了提交，还是rebase得乱七八糟，理论上都能从reflog里找到某个时间点相对完整的状态。这就是为什么急救训练的第一步不是记一堆零散的命令，而是先明白“数据其实还在”，并且“要去找reflog”。

1.2 急救前一定要守住的三条底线

第一条，先跑git status。出错之后，我见过不少人的第一反应是用下一个命令去抵消上一个命令。比如误改了文件，就再改回去；误删了分支，就凭记忆重新建。这样做在极少数情况下能蒙对，但大多数时候只会把现场搅浑。git status会告诉你当前位于哪个分支、暂存区和工作区分别有什么不同，这是所有恢复路径的第一步。有了这个基线，你才知道需要恢复的是工作区、暂存区还是某个commit。

第二条，给当前状态保留一个备份分支。不要嫌多此一举，哪怕是临时执行一句git branch backup-before-fix，也能让你在反复尝试恢复策略时不至于把当前状态再次覆盖。很多人觉得这是浪费十秒，但一个完全可用但不算完美的备份，往往比一个理论上能恢复但没人敢动的现场要强得多。最重要的是，备份分支的成本几乎为零，它只是记录一个commit指针。

第三条，也是最重要的一条，没有把握就不要碰git gc、git prune、git clean -fdx这几类破坏性命令。gc和prune会主动清理未被引用的对象，等于把Git的后悔药直接倒掉；git clean -fdx会删除未被跟踪的文件和目录，其中绝大部分内容从来就没有进过Git对象库，删了就真的找不回来了。急救时宁可多等等，也不要为了让仓库“干净”而提前清场。

1.3 三连命令：10秒定位可恢复点

在确认备份已经留存之后，就可以用三个只读命令快速体检了。第一个是git reflog，它会按时间倒序列出HEAD的移动记录，每一行都有一个hash、操作说明和位置编号。误删分支、reset、rebase、amend这类操作通常都一目了然。第二个是git fsck --lost-found，它会扫描对象库，把没有被任何分支引用的悬空对象找出来。第三个是git branch --contains <hash>，当你已经锁定某个疑似有效的提交时，用它反查这个提交到底还存在于哪一条分支，能省去很多肉眼比对时间。

git reflog git fsck --lost-found git branch --contains <hash>

这三个命令全部是只读的，不会改变仓库状态。在没搞清楚恢复目标前，先把它们跑一遍，相当于在医院里先拍CT再做手术。我见过有同事在误操作后十分钟内连续执行了五六条破坏性命令，结果等真正想恢复时，原来还能找到的悬空对象也被GC清理得差不多了。急救的第一原则，是先让现场保持原样。

2. 工作区和暂存区被改乱：30秒内复原的三种姿势

最常见的误操作，是还没把改动加入暂存区，就执行了git checkout .或git checkout -- 某个文件，结果写完的半截代码没了。这类场景的急救命令相当直接：用git checkout -- 文件名或新版的git restore 文件名，把暂存区里的版本再覆盖回工作区。如果这个文件你已经git add过，那么大概率能恢复；如果只是在工作区里新写的内容且从未add，Git是无能为力的。所以在急救时，第一反应应该是git status看看文件状态，再去决定要不要用restore。

这里有个容易混淆的点：git restore默认恢复的是暂存区版本，而不是HEAD版本。如果暂存区和HEAD一致，那两者没有区别；但如果你先git add了再误覆盖，restore恢复的是暂存区内容，和HEAD不一定一样。想明确从HEAD恢复，用git restore --source=HEAD --staged --worktree 文件会更可靠。不过这属于进阶玩法，普通急救场景下，记住“checkout -- file和restore file能在30秒内把未提交改动找回来”就够了。

2.1 未暂存改动误覆盖：checkout和restore哪个顺手

另一种高频场景，是把不该提交的文件git add了。你以为只要把文件内容还原就没事，其实更应该先把文件从暂存区里请出去。命令是git restore --staged 文件名，Git 2.23之后的新版写法；旧版本则用git reset HEAD 文件名。两者都不会改变工作区文件本身，只是把暂存区里的对该文件的索引清除掉，让它重新变成“已修改但未暂存”的状态。

很多人会误以为restore --staged会把文件恢复成原来的旧版本，其实它和恢复内容没有关系。它改变的只是暂存区的记录。如果你不小心执行了git reset --hard HEAD，同时工作区还有未提交的改动，那这些改动会一起被清掉。这时候不要彻底绝望，因为HEAD本身还可以通过reflog找回，但工作区里那段没来得及保存的原始内容确实有很大概率消失。这是Git急救里最无奈的一条边界。

2.2 暂存后反悔：把文件从索引里请出去

如果误操作的面积比较大，比如改了一大片文件，现在不想立刻处理，又怕继续动会把现场搞得更乱，我会建议先把当前改动收进stash。git stash push -m "备份：xxx"会把工作区和暂存区里的改动打包放到一边，然后工作区回到干净状态；之后可以用git stash list查看，想恢复时用git stash apply stash@{0}。之所以推荐apply而不是pop，是因为apply不会删除stash条目，万一恢复错了，还能再退回去。

stash在Git内部其实也是一个commit，只是被特殊引用refs/stash指着。所以你手滑执行了git stash clear或git stash drop时，看起来列表空了，但它的对象仍然有可能躺在对象库里。这个具体怎么找回，我会在第5节展开。总的来说，stash不只是一个保存临时改动的工具，也是一张在急救过程中很好用的安全网。

2.3 整片改动都要临时挪走：stash也能当急救包

提交之后发现漏了个文件，或者message里有个错别字，这是最轻的翻车。只要这个提交还没有推送出去，git commit --amend就能解决。它会把当前暂存区里的改动合并进上一次提交，同时允许你修改提交信息。如果你只想改信息、不增加内容，可以用git commit --amend --no-edit，它不会打开编辑器，直接保留原来的message。这个命令的本质，是用一个新的提交对象替换旧提交，旧提交会变成悬空对象，不会立即消失。

要注意的是，amend改写的是历史。如果这个提交已经被你推到共享分支，并且其他人已经基于它开始工作，amend之后你需要强制推送，这就会给队友带来一堆同步问题。所以在急救时先问自己一句：这个提交是不是已经不在本地了？如果答案是已经推送，更稳妥的方案是等一等，或者直接用revert。

3. commit 环节翻车：改留言、撤回提交、找回提交，三招救命

当你要撤回本地最近一次提交，但希望代码改动还在时，reset家族是主力。git reset --soft HEAD~1会把HEAD回退一个提交，同时把被回退提交里的变更全部放回暂存区；git reset --mixed HEAD~1是默认模式，它把变更放回工作区，清空暂存区；git reset --hard HEAD~1最激进，会把暂存区和工作区一并恢复成上一个提交的状态。绝大多数新人只想保留改动，结果随手就敲了hard，然后发现写的东西全没了。

选哪个模式，本质上取决于你接下来想怎么处理这些改动。如果你想重新整理暂存区然后再次提交，soft比较合适；如果你想彻底取消这次提交，然后在工作区里继续修改，mixed就够用；只有当你确认那个提交里的内容已经不需要了，才可以用hard。在需要急救的场景里，我的建议是如果只是撤销提交本身，优先考虑soft或mixed，绝不轻易碰hard。

git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1

3.1 只想改最后一次提交：amend解决了什么

提交一旦推送出去，它就不只是你一个人的历史了。此时如果还要用reset强推覆盖，很可能会把别人基于这次提交新增的内容一起冲掉。更稳妥的做法是git revert <hash>，它会生成一个“反向提交”，把目标提交引入的修改在逻辑上抵消掉。历史里多了一条提交，但项目状态回到目标提交之前。之后正常push，不会引发强制推送和冲突风暴。

revert最大的优势是安全，代价是提交历史会多一条。万一revert过程中遇到冲突，说明在你提交之后又有人改过相同区域，这种时候不要硬改，先看清冲突两边内容。你可以git revert --no-commit <hash>先暂存变更，解决完冲突再手动提交。这个流程稍微慢一点，但能在协作分支上避免很多半夜被call的麻烦。

3.2 撤回提交但保留代码：reset的三种模式怎么选

很多人用了reset --hard之后立刻后悔。不管是回退了几个提交，还是把全部分支重置到旧位置，第一件事永远是git reflog。它会把刚才那条“reset: moving to ...”的记录列出来，记录的上一条通常就是reset之前的位置。你只要复制那个hash，再执行git cherry-pick <hash>或git branch 恢复分支 <hash>，就能把丢失的提交重新接回历史。这个操作从定位到恢复，熟练后十秒以内就能完成。

这里要提醒一句：reflog记录的并不是提交内容本身，而是HEAD引用变化的轨迹。如果你在reset后又开了大量的新分支、commit、rebase，旧记录仍然会存在，但位置会越沉越深。如果误操作已经过去了很长时间，比如超过了默认的gc保留期，恢复概率会明显下降。所以发现提交丢了，最忌讳的就是在reflog里看到hash后不立即处理，还想继续写一会儿代码再回来。先把恢复分支建好，后面慢慢看内容都行。

3.3 已推送到远程的提交：不硬改，用revert

合并遇到冲突，属于复现率极高的翻车场景。有时候是几十个文件冲突，你越解越乱，最后只想回到合并前。只要合并操作还在进行中，git merge --abort就能直接取消这次合并，恢复到merge开始前的状态。它的原理是读取合并前保存的分支状态和索引，把工作区、暂存区一起还原。整个过程通常只用一两秒，是急救里性价比最高的操作之一。

这里有个常见的坑：如果冲突发生后你已经手动解决了部分文件，甚至已经git add了，abort一般仍然可以正常执行，因为Git的合并状态还在。但如果你已经git commit生成了合并提交，abort可能就不再适用。此时可以用reflog找回合并前的提交，再执行reset --hard回到那个位置。另外，还有个容易看错的命令是git merge --quit，它只是退出合并流程，并不会恢复文件，不要把它当成abort来用。

3.4 被reset掉的提交：reflog一秒钟找回来

rebase的冲突往往比merge更让人头大，因为提交会一个一个被重放，每弹出一个冲突你都得继续往前推进。很多人在rebase到一半时已经不记得这个分支本来是做什么的，只想赶紧把它弄完。我的建议是，如果冲突超过三个，或者你已经开始在冲突文件里改出不想要的东西，立刻执行git rebase --abort。它会放弃整个rebase操作，把分支恢复到开始rebase之前的提交位置。

有人在rebase中先执行了git add，然后再abort，这是没问题的，因为rebase的底层机制并不依赖你的暂存区来决定继续还是放弃。真正要避免的是使用git rebase --skip跳过那些你可能还需要的重要提交。skip不是急救，它是生产操作。如果你不确定某个该不该跳，宁可abort重来，也不要skip。重来的成本通常小于从一堆被跳过的提交里找回代码的成本。

4. merge和rebase现场的逃生通道

如果merge或rebase已经完成，abort机制失效，还有一个快速方案是使用ORIG_HEAD。Git在merge、rebase、reset等操作前，会把原来的HEAD位置记录在ORIG_HEAD里，有时候git reset --hard ORIG_HEAD就能回到操作之前。但ORIG_HEAD会被下一次类似操作覆盖，如果你在翻车后又执行过其他reset或merge，它就不一定可靠。

所以更可靠的办法仍然是reflog。执行git reflog后，找合并或rebase开始前的那一条记录。它可能不是你紧跟的HEAD@{1}，因为中间的rebase会产生很多临时提交记录。关键要看操作列里有没有 checkout、merge、rebase 字样，找到目标hash后，先确认git show <hash>的内容对不对，再git reset --hard <hash>。在reset前，我建议顺手再建一个临时备份分支，避免又把自己逼到死角。这个双保险的流程，几乎覆盖了所有merge/rebase后想反悔的情况。

4.1 merge冲突不想处理：merge --abort一键回到原点

误删分支是另一个高频事故，常见于分支已经合并到主分支，你把它删掉后才发现里面还有个提交要留着。如果你的误删操作发生在最近，且你之前曾经在那个分支上切换过或提交过，reflog里大概率会留下最后一次在该分支上的位置。比如你从feature分支checkout到main时，reflog会出现一条checkout记录，后面的hash就是feature分支的末梢提交。用这个hash执行git branch feature <hash>，分支就能恢复。

但有一种情况用reflog不一定找得到：分支创建后你从来没有切换过去，或者它的reflog记录已经被清理。这时可以用git fsck --full --no-reflogs --unreachable把所有不被引用的提交列出来，然后逐个git show <hash> --stat查看提交信息，找到属于目标分支的最后一个提交后，再git branch 分支名 <hash>把它恢复回来。这个方法是在没有reflog线索时的兜底，缺点是可能耗时较长，需要一点耐心。分支其实只是个引用，只要提交对象还在，分支就可以被重新指回那个位置。

4.2 rebase冲突太混乱：rebase --abort直接放弃重来

stash被误清也是常有的事。git stash clear会清掉列表，git stash drop会删掉某一条。好消息是，和分支一样，stash本质上是一个commit对象，只是被refs/stash引用。当你执行清空或删除操作时，引用被移走，但对象本身可能还在对象库里等待垃圾回收。恢复时可以先看看git reflog show stash是否还能显示记录，如果能，直接用git stash apply <hash>恢复；如果看不到记录，就继续用fsck来找悬空commit。

用fsck找stash有一个小技巧：dangling commit会显示一堆hash，你很难知道哪个是你要的。可以挨个执行git show <hash> --stat，根据修改过的文件列表和提交message来判断。stash的message通常长得像 “WIP on 分支名: <原commit哈希> 原提交信息”，非常显眼。找到之后，用git stash apply <hash>而不是git stash pop，避免再次误删。这类恢复操作整体不会超过几分钟，但比重新写代码要省力得多。

4.3 abort之外的保底方案：ORIG_HEAD和reflog双保险

和前面所有场景不同，git clean -fd删除的未跟踪文件，是Git无法通过自身机制恢复的。因为这些文件从来没有被写进对象库，Git对它们根本没有任何快照。编辑器如果开启了本地历史，或者操作系统有回收站，那还能碰运气；但单纯靠Git命令，确实无能为力。所以每次看到有人推荐git clean -fd时，我都想多问一句：你知道这句会删掉什么吗？

真正有用的预防手段有两个。一是执行前先git clean -n看预览，列出来的就是待删除清单，确认没有重要文件再执行真正的clean。二是把不想被跟踪的临时文件先加入无关目录，或者用git add -N让文件处于intent-to-add状态，这样git clean时至少会提示它未跟踪但没有被忽略，避免被无脑清掉。急救的本质是尽量把数据放进Git认识的安全区，而不是指望它在工程之外帮你找回文件。

5. 分支被删、stash被清、文件消失：兜底恢复方案

远程分支被强推覆盖是协作场景里最刺激的翻车。你或同事执行了git push --force，把远端分支强制推成了某个旧状态，结果别人刚推送的提交在远端日志里消失。如果那个旧提交在本地或其他同事的clone里还存在，恢复并不难。先在本地执行git reflog找到这个提交的hash，然后用git checkout -b restore-remote <hash>或直接在临时分支上把它推送回远端。如果远端分支被保护，需要临时放开强制推送权限，恢复后重新保护。

这类恢复的关键是时间。强推发生后，旧对象在远端仓库里不一定保留，但如果你或者其他同事在强推前pull过，本地对象库一定还在。越早定位，越不容易被GC清掉。恢复后也要立刻通知团队成员重新拉取，否则他们基于已经被覆盖的远端历史继续开发，就会产生新的分裂。曾经有一个项目因为强推覆盖，某个功能分支的历史整个错位，最后靠一名同事本地clone里的完整对象才救回来，整个过程其实也就半小时。

5.1 误删本地分支：用reflog日志复原分支

讲强推恢复，必须顺带提一下git push --force-with-lease。普通的git push --force会无条件把本地引用覆盖到远端，哪怕远端在这期间已经被别人更新过。而 force-with-lease 会先做个安全检查，只有远端引用还和你预期的位置一致时，它才会执行强推；如果有人已经推了新提交，它会拒绝并给出提示。本质上它给强推加了一道前置确认，很多灾难都能在这一步被拦住。

如果你确实需要强推来恢复旧提交，可以在 force-with-lease 后面加上期望的远端引用值，比如git push --force-with-lease=main:<远端当前hash>，这样更精确。不过在实际急救中，只要远端没有其他人同时操作，直接使用git push --force-with-lease origin main已经足够。把它设成日常push的习惯，比等到翻车后再用30秒恢复要实际得多。恢复历史的最好方式，是根本不制造事故。

5.2 误清stash列表：其实它还是个commit

在多人协作的分支上，最怕的不是单个commit丢失，而是你为了恢复历史又进行了一次强推，反而把其他同事刚刚推送的内容二次覆盖。所以在动手恢复远端前，一定要先和团队确认：我还有这个旧提交的hash，你们那边还有没有别的提交？只要有一方还有完整对象，就可以通过非强制推送的方式把历史重新接上。很多托管平台支持分支保护，设置成禁止对默认分支强推，成本极低，收益极高。

如果你负责维护这些仓库，我建议把“远端仓库永远不是备份”这句话写进团队规范。远端分支再安全，也只是引用和对象的集合；真要保证底账不丢，还是要定期对仓库做镜像或备份。远程事故的急救，说到底拼的不是某个神奇命令，而是你有没有在事故发生前留下足够的可恢复副本。这一点我觉得比任何命令都重要。

5.3 误删未跟踪文件：Git救不了，靠的是预防

这里放一张速查表，覆盖本文提到的高频误操作。表里的命令都在30秒内可以执行完，关键是先判断现场属于哪一行。表格放在手边，比找文档快得多。

这张表不是让你死记硬背，而是当作应急索引。遇到事故先判断属于哪一行，然后执行对应的第一列命令定位，第二列命令恢复。绝大多数恢复只需要一条命令和一次hash确认，所以把时间压缩在30秒内完全可行。真正浪费时间的，往往是犹豫和反复试错，而不是命令本身。

7. 30秒速查表：从翻车现场到恢复命令

7.1 误操作后，先跑这三条命令再决定

有人问，为什么这些误操作大多能恢复？本质是Git用空间换安全。删除分支、reset、amend、rebase都不是物理删除，它们只是把引用从某个位置撕掉，除非触发垃圾回收，否则原始对象一直躺在对象库里。reflog则是离你最近的索引，它记录了引用移动的轨迹。只要reflog或者fsck能定位到那个对象，恢复就意味着把某个分支或HEAD重新指回去。

注意，时机永远是第一位的。默认情况下reflog会保留90天，但如果你使用的仓库长期执行频繁的大型操作，或者被人为执行过gc清理，窗口会更短。所以我把急救口诀总结成三句话：先停手，再查reflog，最后动手。等到确认已经恢复，再用一个分支把结果固化住，别让自己处在一个随时会再次丢失的悬空状态。只要养成这个习惯，30秒拯救误操作不是口号，确实能做到。

7.2 为什么30秒能救回来：reflog和时间的关系

第一，提交前先看状态。git status和git diff只有两行命令，却能让你在commit之前发现不该提交的文件、漏掉的改动和明显的冲突痕迹。很多误操作根本不是手滑，而是根本不知道当前仓库在什么状态。第二，危险命令前给自己留退路。执行checkout、reset、clean之前，先打个备份分支或者至少记下当前HEAD的hash。这个动作花不了十秒，却能让你在翻车之后直接从备份点恢复，而不是去一堆悬空对象里慢慢挖。

我个人在实际项目里还有一个习惯：仓库里永远留一条名为backup或release的稳定分支，隔几天推一次远端。遇到任何不确定的操作，先确认这条分支能顶上，再放心大胆去试。这样一来，30秒急救方案就不再是最后的救命稻草，而是日常开发里一道很不起眼但非常可靠的安全网。希望这篇Git急救笔记对你有用，也希望你用的次数越少越好。