Git急救指南：用reflog和fsck找回误删的提交与文件

1. 看懂 Git 的“后悔药”原理

先说结论：Git 之所以能急救，是因为它根本不是你以为的那种“版本管理工具”，而是一个内容寻址的对象数据库。分支名、HEAD、标签这些你天天打交道的概念，本质上只是一串指向对象库的指针。你每一次commit，实际上是把一次快照写进了.git/objects目录——包括 commit 对象、tree 对象、blob 对象，全部是这个项目在某一个时刻的完整“底片”。

这带来一个反直觉的事实：你平时说的“删掉分支”“reset 回滚”“误操作丢失”，几乎都没有真正删除数据，而只是把指向这些数据的指针移开了。只要对象还在对象库里，就不算真的丢。

这里有个很形象的生活类比：Git 就像一家冲印店，分支名是相册封面上贴的标签，而.git/objects是背后的底片仓库。你把相册标签撕了，甚至把相册扔进碎纸机，底片还在架上摆着。急救的本质就是：用正确的方式找回底片，然后重新贴一个标签。

但既然是急救，就意味着有“救不回来”的时刻。什么情况下真的救不回来？很简单——对象被垃圾回收机制（git gc、git prune）真正清除了。默认配置下，未被引用的对象会在大约 2 周后被清理，而这个时间窗口会随着你的 Git 配置浮动。也就是说，发现误操作后，越快停止写入、越快动手找，成功率越高。

1.1 为什么 reflog 是急救的第一神器

git reflog可能是整个 Git 体系里最有价值的命令，却被绝大多数人忽略。它记录的是HEAD的每一次移动历史——不只是 commit，而是所有让引用发生变动的操作：commit、reset、checkout、merge、rebase、cherry-pick都会在里面留下痕迹。

这句话值得刻在工位上：只要曾经有一个对象被HEAD指向过，它就一定在 reflog 里有记录。你reset --hard丢掉的那个提交，其实只是把指针从那个提交移走了，提交本身还完好地躺在对象库里，并且 reflog 里明确写着“这里曾经是这个状态”。

reflog 的默认保留期限，对已到达的对象是 90 天，对不可达对象是 30 天。这意味着你有至少一个月的缓冲期。我见过最夸张的案例是某开发者在凌晨三点把整个开发分支 reset 得面目全非，第二天下午才想起来求救，照样在 reflog 里找到了原始提交——这就是急救手册的第一根支柱。

1.2 急救操作的三条铁律

铁律一：.git目录还在，一切都有救；.git目录没了，只能靠其他人或其他备份。

很多人遇到误操作，第一反应是“我重新 clone 一份吧”——先别急，你本地仓库的 reflog 和对象库是你唯一的第一手数据来源。一旦你重新 clone，本地这份“事故现场”里的独有对象可能就永远错过了。

铁律二：发现出事，立刻停止一切写操作。

git gc、git prune、git fetch --prune这些会让对象失去引用并加速清理的命令，急救期间一概不要碰。连git status都是安全的，但能忍住不乱敲命令才是高手。最稳妥的做法是：先复制一份.git目录做快照：

cp -R .git .git.bak-$(date +%Y%m%d%H%M)

这条命令只花几秒，成本极低。但有了这个备份，后面无论怎么折腾，心里都踏实很多。

铁律三：动手前先把当前状态完整记录一遍。

git reflog | head -50的输出、当前git status的原文、以及你怀疑“丢了”的那个东西大概是什么时候消失的——把这三样记录到文本文件里。急救最怕的不是不知道用什么命令，而是搞了半天，把一个本可以恢复的状态又覆盖掉了。先存证，再施救，这是专业操作和运气操作的本质区别。

2. 文件级急救：找回丢失的工作区内容

这是发生频率最高的一类场景。辛辛苦苦改了一上午的代码，一次git restore .、一次git checkout -- file、一次git clean -fd，全部清零。先分清楚：你丢的是什么阶段的内容？这个问题的答案直接决定了抢救方案。

2.1 还没 commit 也没 add 的内容怎么办

直说：如果内容从没被 Git 追踪过，那 Git 自己确实无能为力。Git 只记录“被提交或被暂存过”的数据，从来没进入过 Git 视野的纯工作区内容，在对象库里没有对应底片。

这类情况下，真正的救命稻草通常是 IDE 的本地历史功能。某些编辑器的 Local History 默认开启，会定时保存文件的历史快照；某些编辑器的备份目录里也留着.bak文件。如果你用的是命令行 + 简单编辑器，那补救只能靠肌肉记忆重写。

但这里有一个很多人都没意识到的中间状态：如果你曾git add过某个文件（哪怕后来又继续改了），那你暂存过的那个版本是留下过对象的。也就是说：写完一段逻辑 → 顺手git add→ 继续改 → 误操作清空了工作区。此时 Flo 的救法不是没有，而是走git fsck。

git fsck --lost-found

命令跑完之后，Git 会把所有“悬挂”的对象（没有引用指向但未被清理的对象）放到.git/lost-found/other/目录下。这些文件的命名是哈希值，没有原始文件名。你需要一个个用file命令识别类型：

file .git/lost-found/other/*

如果运气好，里面会有你曾经暂存过的文件内容。虽然找回后是哈希名，但内容对了就成功了大半。这说明一个实操经验：重要进度，哪怕只是写了一半，先 add 一下不亏。因为git add其实是把内容写进对象库，这一下就成了你的“保险绳”，而git restore/git reset --hard都清不掉对象库里的东西。

2.2 已 commit 的内容被 reset --hard 丢了

这是 Git 急救里最经典、也最好救的场景。细节是：只要你的提交曾被HEAD指向过，reflog 里就有它的哈希。

举个例子，某开发者在分支上做了一次提交a1b2c3d，然后觉得代码不行，执行了git reset --hard HEAD~2，把分支指针往后挪了两步。此时a1b2c3d看起来“没了”——但 reflog 里完整记录着。

第一步：查看 reflog，找到目标提交的前面几行：

git reflog

输出大致长这样：

a1b2c3d HEAD@{0}: reset: moving to HEAD~2 f9e8d77 HEAD@{1}: commit: 完成XX功能 a1b2c3d HEAD@{2}: commit: 完成YY重构

这里HEAD@{1}就是你误操作之前的分支位置。第二步，直接复位回去：

git reset --hard f9e8d77

一切恢复如初，比想象中简单。核心原理：reset只是移动了引用，对象库里的提交一个都没少。只要 reflog 还在，这就是一个三秒钟的救援。别再对着屏幕哀嚎了，先跑git reflog。

2.3 文件被删除或覆盖后的定向恢复

如果你不是想整体回退，而是只想恢复某个被删除或改坏的文件，不用动整个分支。Git 提供了非常精准的命令：

git restore --source=<某个commit哈希> -- 文件名

比如你误删了config.js，而你在上次提交abc123里见过它，那么：

git restore --source=abc123 -- config.js

这条命令的意思很明确：用指定提交里的版本覆盖工作区。它不改变当前分支指针，不触动其他任何文件，是最小化操作。

还有一种特别容易踩坑的情况：git clean -fd把未跟踪文件删了。这个命令的杀伤力极大，因为它删的是“从未被 Git 记录过”的文件，reflog 帮不上忙。此时同样只能靠git fsck --lost-found碰运气——如果你在删除前曾经 add 过这些文件，有机会找回；如果从来没 add 过，则完全无法恢复。所以，git clean是我见过被滥用得最严重的危险命令，执行前一定要先跑git clean -n预览，别问为什么，等你吃过亏就懂了。

2.4 stash 丢失的救援

git stash操作的原理是什么？它是一个特殊的 commit，存储在.git/refs/stash。所以当你执行git stash drop或git stash clear时，本质上是删掉了一个指向 stash 提交的引用——但 stash 提交本身还挂在对象库里，只是变成了“不可达”状态。

救援步骤分两步走：

git fsck --unreachable | grep commit

输出里会列出所有不可达的 commit 哈希。挨个用git show <哈希>查看，确认哪一个是你的 stash。找到之后，直接应用：

git stash apply <哈希>

这个操作相当于把 stash 里的改动重新应用到工作区。注意用apply而不是pop，因为原 stash 引用已经没了，你不需要“弹出”，只需要“应用”。恢复完成后建议立刻为该提交创建一个分支做保险：

git branch recovered-stash <哈希>

这样这个 stash 提交就重新有了引用，再也不用担心被 gc 清理了。

3. 提交级急救：修正错误提交

文件救回来了，接下来处理“提交本身出错”的各类状况。这一类问题的特点是：数据没丢，但历史记录不符合预期——要么提交信息写错了，要么提交内容多带了一个不该带的文件，要么提交后立刻发现代码有低级错误。

3.1 最近一次提交想改动：commit --amend

如果错误发生在“最近一次提交”，而这次提交还没有被推送到远程，git commit --amend是最优雅的方案。

场景一：提交信息写错了。

git commit --amend -m "正确的提交信息"

这个操作会生成一个新的提交对象，替换掉原来的提交。因为内容可能完全一致，所以看不出区别，但哈希会变。注意：amend 的本质是“用新提交顶替旧提交”，不是就地修改，所以它同样会改写历史。

场景二：提交时漏了某个文件，或者手滑多加了文件。

git add 漏掉的文件 git commit --amend --no-edit

--no-edit的意思是保留原有的提交信息，不用重新编辑。如果你是多余加了文件，用git restore --staged 文件名先取消暂存，再 amend 即可。

3.2 选择 reset 的哪种模式，是个策略问题

这里必须把git reset的三种模式给彻底讲明白，因为太多人只知道--hard，然后哭着找 reflog。三者的区别只在“指针移动时，暂存区和工作区是否跟着动”。

举两个具体例子。

想撤销“误提交但保留改动”：你git commit后立刻发现提交信息写错了，或者根本不该提交。此时用git reset --mixed HEAD~1，改动会回到工作区且处于未暂存状态，文件内容完好无损。接下来重新 add、重新 commit 即可。

想把最近三个提交合并成一个：先git reset --soft HEAD~3，这样三次提交的改动全部回到暂存区，然后一次性git commit，历史就干净了。

什么情况用--hard？我的建议是：除非你 100% 确认改动内容完全不需要了，否则一律先用--mixed。哪怕后面真的想丢弃，再执行一次--hard也不迟。但反过来，一旦先--hard，你又忘了保存当前的逻辑细节，就只能靠 reflog 找回来——过程虽然可行，但平白多增加风险，何必呢。

3.3 已推送的坏提交:用 revert 而不是 reset

如果错误提交已经push到远程分支，情况就复杂了。你和团队共享的分支上，任何改写历史的操作都会导致所有人的仓库出现分叉，轻则让同事 pull 时产生冲突，重则把别人已经基于旧提交开发的代码搅得一团糟。

这时候的正解是git revert：

git revert <坏提交的哈希>

revert不是删除坏提交，而是生成一条新的提交，内容恰好是坏提交的反向操作。历史链条保持线性，其他协作者的仓库不会有任何感知障碍——他们下次pull时，只是看到多了一条新提交。

这里有几个实操要点：

1. 多个连续坏提交怎么 revert？可以一次性 revert 一个区间：git revert --no-commit HEAD~3..HEAD，然后手工 review 产生的改动再提交。
2. revert 后又想恢复？直接再 revert 那一条 revert 提交即可，简单明了。
3. merge commit 可以 revert 吗？可以，但要带-m 1参数指定主线：git revert -m 1 <merge提交>。这表示“撤销这次合并带来的所有改动，保留主线内容”。

我把这条写进过太多团队的 Git 规范里：一旦提交进了公共分支，就把“改写历史”四个字从字典里删掉，一律用 revert。除非你面对的是严重安全漏洞，或者说你们团队人少到可以接受全员重新 clone。

3.4 rebase 中途或完成后后悔了

git rebase是误操作的重灾区，因为它的介入性太强——每一步都可能改提交、产生冲突、改变哈希。

场景一：rebase 进行到一半，冲突解决不下去，想放弃。

git rebase --abort

这条命令会把 rebase 操作完全回滚，回到 rebase 开始前的状态。注意区分：git rebase --skip是跳过当前提交继续，--abort才是彻底放弃。操作乱了别硬扛，一声 abort 就能回到原点。

场景二：rebase 完成了，但结果不是想要的。

这里的关键在于——即使 rebase 已完成，rebase 前的提交也还留在对象库里。通过 reflog 找到 rebase 之前的分支位置：

git reflog

在输出里找类似rebase (finish): returning to refs/heads/feature或checkout: moving from feature to ...的记录，前面就是 rebase 前的哈希。确认后直接复位：

git reset --hard <rebase前的哈希>

整个分支就回到了 rebase 之前的状态。这个操作我实际用过不止一次：把特性分支 rebase 到最新的主分支后，发现冲突解决过程中丢了一处关键逻辑，reset 回去重新来。记住，reflog 是你做任何危险操作前的“预防针”。

4. 分支级急救：找回被删和失控的分支

分支是 Git 里最容易“消失”的东西，但也是最好找回来的东西。理解这一点需要回到开头的原理：分支只是一个 41 字节的引用文件。删分支只是删了这个文件，所有提交对象一个不少。

4.1 误删的分支怎么原地复活

先说一个习惯问题。某开发者在清理临时分支时执行了git branch -D temp-feature，随后发现分支里还有一个写了一半的功能。当时我也帮他跑了一遍完整的救援流程，步骤如下：

第一步，列出所有不可达的提交：

git fsck --full --no-reflogs --unreachable

这里加上--no-reflogs的意思是：不要因为 reflog 中还有引用就忽略这些对象，强制列出所有不可达提交。输出里会有一串unreachable commit ...字样。

第二步，逐个查看这些提交的内容：

git show <哈希> --stat

看哪个提交包含你丢失的功能文件。确定之后，用一条命令复活分支：

git branch temp-feature <哈希>

分支回来了，里面的代码也回来了。整个过程不超过五分钟。

有个非常重要的经验值得写下来：git branch -D和git branch -d的区别，用过一次就忘不掉。-d会在分支未合并时拒绝删除并给出警告；-D直接强制删除，不给任何确认机会。所以我建议所有开发者在心里给自己立个规矩：临时分支一律用-d，只有确认要丢弃时才手动改-D——多一层确认，少一次事故。

4.2 游离态 HEAD（detached HEAD）脱困

另一种常见的“失控”状态：某天你用git checkout <某个旧哈希>检出了历史提交，然后在上面改了代码并 commit。此时你的提交没有任何分支引用，HEAD 处于游离状态。如果此时你直接切走，从这个游离提交开始的整个新提交链会变成不可达对象，看起来“丢了”。

在这类场景中，救法反而比误删分支更简单。先通过 reflog 找到游离提交的哈希：

git reflog -5

显示的历史尾部记录里，通常有checkout: moving from ... to <哈希>。把游离提交创建为一个正式分支：

git branch recover-work <哈希>

然后切过去继续开发：

git checkout recover-work

就这么简单，那几个“丢了”的提交从此有了名字，再也不会被垃圾回收。实际上游离态提交本来就没有丢失，只是没有分支引用，这只是一种“临时孤儿”状态，给它一个分支名就是认领。

4.3 误 merge 后回退

git merge合并错了分支，或者合并后发现有大量冲突，想回到 merge 之前的状态。

两种情况：如果没有冲突，merge 已经生成了 merge commit，且你还没推送。那么用 reflog 找到 merge 前的哈希，git reset --hard <merge前的位置>即可，这个操作和普通回退完全一致。

但如果 merge 提交已经推送到远程公共分支了，就按 3.3 的方式用git revert -m 1 <merge提交>。这里再次强调-m 1的作用：merge 提交有两个父提交，-m 1表示以“你执行 merge 的时候所在分支”为主线来生成反向改动。如果不带这个参数，Git 不知道你想退回哪一边，会直接报错。

5. 远程与极限场景：最后一道防线

5.1 本地 reset 完，发现远端还没同步

有一种特别容易发生的情况：你在本地git reset --hard回退到某个旧状态，然后把工作区里新写的文件一通折腾，最后发现“我把上次已经 push 到远端的提交弄丢了”。

这类情况需要注意的地方在于：如果远端在你 reset 之后没有被你强推过，远端还保留着完整的最新提交链。这是最好办的一种：

git pull --rebase

或者直接：

git reset --hard origin/<你的分支名>

把本地分支强制拉回到远端最新状态，丢失的内容全回来了。

但麻烦的情况是：如果你 reset 之后又用git push --force强推了远端，那远端那个旧引用也被你覆盖了。此时还有两条路可走：

一是找同事的本地仓库。Git 对象在 clone 之后是完整的，同事本地仓库的 reflog 里通常还留着之前同步时的记录，可以借他的仓库把对象捞回来。具体操作是：在同事的仓库里定位到那次提交，git format-patch导出，或者直接用git bundle打包发给同事。

二是回头检查托管平台是否保留强制推送前的对象。部分代码托管平台对强推会短暂保留旧对象，但千万不要把希望全押在这上面。真正的保险永远是：重要分支开启保护，禁止强推；强推前先创建 tag 或备份分支。

5.2 敏感信息进仓库：止血、清史、轮换

这是 Git 误操作里最严重的一类。提交了密钥、证书、包含密码的配置文件、或者体积巨大的二进制文件。

先说止血：立即用git revert删除那条提交，并强推远端。这样线上代码恢复正常，历史里依然存在敏感信息，但至少其他协作者 pull 到的已经不是“坏代码”。

然后是清史：如果不希望仓库历史里永远躺着这个文件，只能用改写历史的方式。Git 官方推荐的工具是git filter-repo，执行前先在一个干净的 clone 上操作：

git clone --mirror <你的仓库地址> repo.git cd repo.git git filter-repo --invert-paths --path 敏感文件路径

重复一遍，filter-repo 一定要在副本上跑，它会重写所有提交的哈希，原仓库需要全组统一替换。期间所有成员都要pull新远程、重新 clone。这个代价非常高，所以这个操作应该作为最后手段。

最后但最重要的一步，也是很多人忽略的一步：历史里的密钥必须作废重发。因为仓库历史可能已经被别人拉取过，即使filter-repo改写了当前所有协作者的本地仓库，谁也不能保证副本不会外泄。所以清史只是“消除隐患”，轮换密钥才是真正的“解除危机”。同样地，如果误提交的是大文件，先git filter-repo移除，然后考虑给.gitignore加上对应规则，并检查是否有持续集成产物被误提交的问题。

5.3 整个本地仓库损坏或被删

严格说这已经超出“误操作”范畴，更像是灾难恢复。但急救手册里必须包含这类极限场景。

如果.git目录整个被删了（比如执行了rm -rf .git），但工作区文件还在，最基础的抢救方案是：

git init git remote add origin <远程仓库地址> git fetch origin git add -A git commit -m "重新初始化"

这样能保住当前代码的快照，但历史全部丢失。如果有其他人 clone 过这个仓库，从别人的.git目录里打包拿一份回来更实际，因为对象库是完整可复制的。

还有一种更隐蔽的损坏：.git/objects里某个对象文件损坏，导致git log报错。先跑git fsck --full看具体缺失哪些对象，如果损坏的是某个不重要的 blob，可以尝试从其他 clone 里手动复制对应对象文件到.git/objects的对应路径，或者直接从备份恢复整个.git。但说实话，这类修复的性价比很低，与其花两小时修一个坏对象，不如直接重新 clone，然后按 reflog 或备份补回本地独有提交——除非你确信本地的某个提交在远程不存在，否则别浪费时间。

6. 误操作急救速查表与避坑清单

6.1 一张表解决 90% 的常见误操作

这张表是我实际处理过的事故场景的浓缩。你可以把它打印出来贴在工位上，或者直接记在笔记里。遇到问题先对表，比抓瞎乱敲命令强一百倍。

6.2 避免误操作的工作习惯

急救当然重要，但真正的高手从来不是靠急救活下来的，而是靠习惯把事故发生率降到最低。

第一个习惯：重要节点打 tag。Tag 本质上也是引用，它让提交有了一个稳定的名字。哪怕之后你 reset 一百次，只要有 tag 指在那个提交上，它就永远不会被 gc 清理。

第二个习惯：少用checkout切历史，多用switch。git switch -c new-branch的语法比git checkout -b new-branch清晰，它明确告诉你“我要切换到新分支”，而不是一个能同时干一百件事的万金油命令。同理，单文件恢复用git restore，不要再用git checkout -- file，让每个命令的职责边界尽量清晰。

第三个习惯：分支命名要可读。fix1、test123、temp22这种名字，回收的时候根本分不清里面有没有重要内容，于是就会顺手-D，于是就会出事。尝试fix/登录超时、feature/订单导出，即使出问题，你也能从名字判断价值。

第四个习惯：push 前 review，reset 前三秒。每次 push 前跑一句git diff origin/<当前分支>..HEAD，看一眼即将上线的内容；每次执行git reset --hard前，先默念三秒“我真的确认了吗”。

第五个习惯：给危险命令留一层保险。如果你需要在某个分支上做大规模重构，先创建备份分支：

git branch backup/功能-20240115

刷新成习惯之后，你会发现急救手册大多数章节其实用不上——但有限那几次用上的时候，它就是救命的。

我自己这些年处理过的 Git 事故，几乎全发生在深夜赶版本或者长时间高强度协作的时候。人一旦疲惫，手就比脑子快，误操作的概率直线上升。所以我最后再分享一条经验：与其相信自己不会犯错，不如提前在安全的环境里把上面这些误操作故意犯一遍——建一个练习仓库，把reset --hard、rebase --abort、fsck --lost-found全部实测一遍。等你真正置身事故现场时，因为肌肉记忆已经有了，反而会格外冷静。

记住两个最核心的咒语就够了：git reflog是救命稻草，.git目录是最后防线。祝你好运，希望这篇手册永远躺在收藏夹里而不是被翻出来救火。