Git提交丢失怎么办？一文精通git reflog恢复实战

不知道你有没有过这种时刻：在 Git 里一顿操作猛如虎，git reset --hard敲下去，发现刚写了大半天的代码连同提交一起人间蒸发；或者git rebase到一半发现冲突太乱，直接git rebase --abort，结果之前那个“看起来没用”的分支也跟着消失。我当年刚开始用 Git 时，第一次遇到这种情况，第一反应是满头冒汗，第二反应是翻遍整个项目目录找有没有.bak文件。后来才认清一个事实：在 Git 世界里，只要一个对象曾经被提交过，它就没有真正“消失”，只是你暂时不知道去哪里找它。而这一切的钥匙，就是git reflog。

这篇文章只讲一件事：git reflog到底是什么，以及当你“丢”了提交时，怎么用它把东西捞回来。我会从它的底层机制讲起，再用真实场景带你走完“搞砸 → 找到 → 恢复”的完整流程，最后整理一份我自己踩过无数次坑才总结出来的排查手记和恢复避坑清单。无论你是刚开始接触 Git 的新手，还是已经写了几年代码但一直没细看 reflog 的老手，这篇文章都能给你一套直接能用的救命方案。

1. 先搞懂一件事：reflog 到底是什么

1.1 一个容易被忽略的“操作日志”

很多人第一次听到 reflog 时，会把它当成git log的变种，觉得“不就是看提交记录嘛，git log我也天天用”。实际上这两者的视角完全不一样。git log展示的是当前分支上的提交历史，它回答的问题是“这条分支从起点到现在经历了哪些提交”。而git reflog记录的是HEAD 引用的变化日志，它回答的问题是“你的仓库状态在过去一段时间里经历了哪些移动”。

什么叫“HEAD 引用的变化”？我举个例子。你在main分支上，执行了一次git commit，HEAD 从原来的提交 A 移动到新提交 B，这就是一次引用变化，reflog 会记一条。你执行git reset --hard HEAD~1，HEAD 从 B 移回 A，这又是一次引用变化，reflog 也记一条。你切分支git checkout dev，HEAD 从 main 的指针切换到 dev 的指针，reflog 同样记一条。甚至你在本地执行git merge、git rebase、git cherry-pick，所有这些会移动分支指针或 HEAD 的操作，reflog 都会留下痕迹。

这个设计太关键了。它能让你把时间稍微往回拨一点，看到仓库在某个操作之前指向哪里、之后又指向哪里。很多情况下，你“丢失”的提交并不是被删除了，而是因为指针移动，从某个分支的可见历史里消失了。只要你在 reflog 里找到那条指针曾经停留过的位置，就能顺着位置把提交找回来。

1.2 reflog 的记录位置和生命周期

reflog 不是动态分析出来的，它是持久化存储在 Git 目录里的。具体来说，每个仓库都有一份全局的 reflog，记录 HEAD 的变化；每个分支也有自己的 reflog，记录该分支指针的变化。这些信息存放在本地仓库的.git/logs/目录下，比如.git/logs/HEAD文件就是全局 reflog，.git/logs/refs/heads/main就是 main 分支的 reflog。

这些文件是纯文本格式，每一行对应一次引用变化，格式大致如下：

<旧commit哈希> <新commit哈希> 用户名 <邮箱> <时间戳> 操作描述

所以你完全可以理解成：reflog 就是一个操作审计日志，只不过它的“操作”不是你的键盘输入动作，而是 Git 引用指针的每一次移动结果。

reflog 默认有 90 天的生命周期。也就是说，一个提交对象如果在 90 天内被 reflog 引用到，它是可以找到的；如果超过 90 天没有在任何 reflog 条目中出现，而且没有被其他分支或标签引用，那它就会进入真正的“可以被清理”状态，后续会被git gc回收。这个 90 天是可以配置的，通过gc.reflogExpire和gc.reflogExpireUnreachable两个配置项控制。绝大多数情况下默认值就够用，但如果你做大型重构，频繁 reset 和 rebase，又担心某些中间状态以后要用到，可以适当调大这个期限。

注意：reflog 保存在本地，本地仓库被别人 clone 走之后，对方并不包含你的 reflog。reflog 本质上是你本地操作的私有记录，不是提交历史的一部分。

2. 哪些操作最容易弄丢提交：真实场景还原

2.1 场景一：reset --hard 把提交打没了

这是最常见的一种“丢提交”方式。你正在开发一个新功能，写了几个提交，但后来觉得思路不对，想回到两天前的某个状态重新开始。你执行了：

git reset --hard HEAD~3

执行完你发现，不光是工作区代码变回三天前了，关键是你之前写的几个提交也不在当前分支的历史上了。我见过很多人到这一步就开始紧张，甚至有人直接.git目录里翻找，其实完全没必要。因为这几个提交在 reset 之前，是实打实存在于dev分支上的，所以dev分支的 reflog 里一定还留着它们的记录。

你只需要执行：

git reflog

就能看到类似这样的输出：

0a1b2c3 HEAD@{0}: reset: moving to HEAD~3 7f8e9a0 HEAD@{1}: commit: 完成登录模块重构 ...

这里的7f8e9a0就是你 reset 之前指向的提交。所有你“丢掉”的提交都还在，只是分支指针往后退了而已。

2.2 场景二：rebase 搞到一半，abort 之后分支丢了

我最初用 rebase 时，对它的理解特别肤浅，总以为 rebase 会把原提交原地改写，后来才明白它其实是“复制新提交、移动指针”的过程。如果你在 rebase 过程中遇到一串冲突，处理到心态爆炸，直接敲了一个git rebase --abort，Git 会把当前分支的指针恢复到 rebase 之前的状态。

问题在于，rebase 的过程中 Git 会创建很多中间状态的 commit 对象，abort 之后这些对象虽然不再被分支引用，但它们并没有立即删除。只要你在 rebase 操作期间有任何一个引用移动被 reflog 记录下来，就能通过 reflog 找到。尤其是那种“处理了几个冲突，已经手动改了一部分代码，结果被迫 abort”的场景，那些没提交的改动可能确实没了，但原本分支上的提交一定还在 reflog 里。

2.3 场景三：cherry-pick 选错了提交，回退后发现原分支也不见

还有一种情况是你想从一个分支摘取某个 commit 到当前分支，执行git cherry-pick之后，发现代码跟当前分支状态冲突太多，又执行了git cherry-pick --abort。此时 GitHub Desktop 或 IDE 可能会提示你“操作已取消”，但 cherry-pick 过程中创建的新提交对象已经生成过一次，即使 abort 也会在 reflog 里留下痕迹。

类似的还有git revert之后又觉得不该 revert，或者git branch -D删除分支后发现分支上还有没合并的代码。这几种场景的共性是：你执行了一个会让分支指针移动的操作，但该操作之前的状态还记录在 reflog 中，所以都可以恢复。

2.4 场景四：stash 被误清

很多人不知道git stash的操作也会写入 reflog。因为当你执行git stash，Git 本质上是在创建一个特殊的 commit 对象（它有多个 parent，索引状态和工作区状态），然后把 stash 引用指向它。如果你执行了git stash clear，心里想的是“清掉所有缓存”，结果发现里面有一个存了很久、差点忘了但是很重要的临时改动，这时候 reflog 同样能捞回来。

不过 stash 的恢复稍微特殊一点，你不能直接用git cherry-pick或者普通git merge去处理，而是要把那个 stash commit 转换成一个新分支，再做合并或挑选。后面我会具体讲方法。

3. reflog 实战恢复：一步步把提交捞回来

3.1 先学会读懂 reflog 输出

打开终端，进入你的仓库，执行git reflog，输出最前面几行是这样的：

c3240a2 HEAD@{0}: reset: moving to HEAD~3 b57a901 HEAD@{1}: commit: 修复编辑器光标跳动问题 e8d2f40 HEAD@{2}: commit: 完成快捷键模块 9a70b43 HEAD@{3}: commit: 新增图片上传组件 f63c2d8 HEAD@{4}: checkout: moving from feature/login to main

每行从左到右分别是：当前该条引用所指向的提交哈希、HEAD 的相对位置、操作类型和描述。其中HEAD@{0}表示当前 HEAD 的位置，HEAD@{1}表示“HEAD 上一次所在的位置”，数字越大代表越早。

在最常见的恢复场景里，你只需要做两件事。第一，确定自己“丢”的提交是哪一个。方法很简单，看 reflog 里有没有一条记录，它的描述是commit: xxx，而且这个 commit 的哈希不在你当前的git log里。第二，确定你要回到哪个位置。目标位置通常就是那条记录左侧的哈希值。

补充提示：如果你不确定某个哈希具体对应哪个提交，可以用git show <哈希>查看；如果你想知道某个提交包含了哪些文件改动，可以用git show --stat <哈希>。

3.2 恢复方式一：直接在当前分支上重建指针

如果丢失的提交本来就在你想要保留的分支上，只是分支指针被回退了，那么恢复手段非常简单：

git reset --hard b57a901

这一条命令会把当前分支的指针拨回到b57a901这个提交上，同时工作区文件也会恢复到该提交对应的状态。执行完之后你再用git log看看，之前那几个“消失”的提交就都回来了。

有人可能会问：“我这个提交已经过去好几天了，reflog 里还能看到吗？”只要在 90 天生命周期内，大概率还在。因为 reflog 记录的是引用移动历史，只要那次移动的旧值仍然保留在.git/objects里且未被 gc，reflog 的内容就会一直存在。

3.3 恢复方式二：用临时分支承接，再合并

有时候你并不想把当前分支硬生生地回退到那个提交，因为当前分支后续又新增了很多提交。这时候直接在目标位置git reset --hard会把后面这些新提交也丢掉，不太合适。

正确的操作是：以目标提交为基础，新建一个临时分支，然后再决定怎么处理。

git branch recover-branch b57a901 git checkout recover-branch

这条命令的含义是：在b57a901这个提交处创建一个名为recover-branch的分支，然后切换过去。此时你会进入一个包含“丢失提交”的完整分支。之后你可以用git cherry-pick、git merge、git diff等常规操作，把需要的内容整合到主分支上。

这种方式特别适合“那个提交在一个被删除的分支上，我想把它内容取回来”的情况。你不需要恢复原分支名，直接用临时分支就够了。我自己通常习惯用temp-recover这种前缀命名，方便后面清理。

3.4 恢复方式三：stash 被 clear 后的特殊找回

针对 stash 被清的情况，reflog 路径略有不同。你不能通过普通的分支 reset 直接恢复成 stash 状态，因为 stash 本身是一个特殊的引用。操作步骤如下：

git reflog show stash

这条命令会单独展示stash引用的 reflog，而不是 HEAD 的 reflog。你会看到类似这样的输出：

a1b2c3d stash@{0}: WIP on feature/login: 4fc97e8 完成登录模块重构

这就是你之前 stash 的那个提交。恢复的方式是把这个 stash commit 变成一个分支：

git branch recover-stash a1b2c3d

然后切换到该分支，再把这个分支上的改动 merge 回你原来的开发分支。或者你也可以直接用：

git stash apply a1b2c3d

这种方式会直接把 stash 改动应用到当前工作区，相当于恢复了 stash 内容但保留 stash 引用（不会弹出它）。

3.5 恢复方式四：对象还在但 reflog 被部分覆盖

有一种更棘手的情况：你执行的操作量非常大，reflog 里包含的条目太多，早期记录被冲掉了。但提交对象本身可能还没有被 gc 清理。这时候可以借助git fsck来找“孤儿提交”。

git fsck --lost-found

这条命令会扫描仓库中所有没有被任何引用指向的提交对象，输出类似dangling commit a1b2c3d的形式。这些 dangling commit 往往就是那些“看似消失但还躺在对象库里”的提交。

拿到哈希后，你可以用git show a1b2c3d查看是不是你想找的提交，确认后用前面提到的方式把它恢复为分支。这个方法算是 reflog 的补充方案，适用于 reflog 生命周期已过或者条目被覆盖的情况。

4. 恢复过程中的常见问题与排查技巧

4.1 reflog 里条目很多，找不到目标提交怎么办

我刚开始练习恢复时最大的困扰就是 reflog 输出太长，尤其是需要恢复的提交发生在好几天前，中间又穿插了大量无意义的操作记录。这时候可以通过几个命令来辅助筛选。

办法一：用时间倒序逐条查看

git reflog --date=iso

这个命令会在每条记录后面显示具体的操作时间，方便你确认自己大概是在哪个时间点搞丢的提交。

办法二：配合 git log 对比当前历史

git log --oneline --graph --all

这个命令会把所有分支和标签能到达的提交画成一张图。如果你的丢失提交不在这张图里，说明它确实是一个孤儿提交，reflog 才是主要搜索入口。

办法三：直接在 reflog 里搜索特定提交信息

如果你还记得丢失提交的 commit message，用git reflog | grep "关键词"是一个效率很高的方式。因为 reflog 每一行都包含操作描述，commit message 的关键字往往能帮你直接定位。

4.2 恢复后发现工作区代码“不对”

这种情况经常发生在git reset --hard恢复之后。你执行了恢复命令，但在编辑器里看到的代码却不是你预期的那一版。原因可能有两个。

第一个原因是恢复目标选错了。你以为HEAD@{2}是你想要的位置，但实际上那一天你在这条分支上有多个提交，HEAD@{2}可能比预期早或晚了一次提交。排查方法很简单：在 reset 之前，先用git show HEAD@{2} --stat看看这个提交的改动内容，确认符合预期了再动手。

第二个原因是当前工作区本来有未提交的改动，恢复操作把它们覆盖掉了。我在生产上吃过这个亏，好在后来养成了习惯：任何reset --hard之前，先看一眼git status，有未提交改动就先git stash。stash 之后如果再后悔，还能通过前文讲的方法恢复。

重要提示：执行git reset --hard之前，一定要确认工作区的未提交改动。如果这些改动没有 commit 也没有 stash，git reset --hard会直接丢弃它们，reflog 也没办法帮你找回。

4.3 恢复后处于游离的 HEAD 状态

如果你用git checkout <哈希>而不是git checkout <分支名>或git reset --hard <哈希>，Git 会进入 detached HEAD 状态。在这个状态下，你虽然能看到代码内容，但所有新的提交都不属于任何分支，一旦切走，这些新提交就变得难以追踪。

解决方法有两个。如果你只是临时查看代码，看完后切回原来的分支即可。如果你想在游离状态下继续开发，建议立刻执行：

git switch -c new-branch-name

这会基于当前游离 HEAD 创建一个新分支，并把 HEAD 移到新分支上。之后所有新提交都会记录在 new-branch-name 上，不会再丢。

4.4 reflog 已经被 gc 清理了怎么办

如果你的“丢失提交”时间非常久远，超过了 reflog 的 90 天默认期限，且这期间你执行过git gc或者触发过自动 gc，那 reflog 条目很可能已经被清理，提交对象也可能被回收。这种情况能恢复的概率就大大降低了。

不过你还是可以试试git fsck --lost-found，看有没有残留的 dangling commit。如果 fsck 也找不到，那基本上可以确认对象已经被彻底清理了。这也是为什么我对新人反复强调：凡是重要的提交，一定要及时推送到远程仓库，或者至少创建一个分支长期引用它。reflog 是保险丝，不是保险柜。

4.5 常见“丢提交”场景快速恢复对照表

5. 那 reflog 这么神，能当日常工具用吗

5.1 用 reflog 找回“误删”的本地分支

上个月我就经历过一次，本地有个feat/payment分支，因为觉得功能已经没用了，直接git branch -D feat/payment。后来产品经理说那个功能还要看一版，我当时脑子里飞速转了一圈，印象里分支没推到远程，原以为彻底没了。后来冷静下来，用git reflog找到分支最后一次引用的提交，一秒恢复：

git checkout -b feat/payment 3f8c21d

这里要特别说明：git branch -D删除分支时，分支的 reflog 也会被一并删除。但 HEAD 的 reflog 不会因此消失，因为你在该分支上开发时，每次提交、切换分支都会导致 HEAD 指向的移动，都会记录在全局 reflog 里。所以通过全局 reflog 依然能定位到分支最后一次的提交。

5.2 用 reflog 排查“代码被同事还原了”的疑案

还有一种很有趣的用法：团队合作时，别人在你本地分支上执行过 pull、merge 或者 reset 操作，你发现代码好像被人动过。因为 reflog 记录的是本地仓库的引用变化，你能清晰地看到每次 reset、merge 的具体时间、进出方向。虽然不是每个团队都有完善的 code review 流程，但 reflog 至少能帮你还原“本地发生了什么”。

5.3 用小技巧给 reflog 增加“锚点”

如果你想确保某个提交不会因为 reflog 过期而丢失，可以给它打一个标签，让标签长期引用它：

git tag backup/2025-important-state 3f8c21d

标签分为轻量标签和附注标签，这里用轻量标签就够了。tag 会创建一个固定的引用，只要你不手动删除它，相关的提交对象就会一直存活，不会被 gc 清理。这算是我个人非常推崇的一个习惯：大的里程碑提交、或者“虽然要清掉但保不齐以后要看”的提交，随手打个 tag，省得以后靠 reflog 到处翻。

5.4 配合 aliases 让 reflog 更好用

如果你觉得git reflog输出太长，可以配置一个别名，把它变成带时间、更紧凑的格式：

git config --global alias.rl "reflog --date=iso --pretty='%h %gd %gs'"

这样你在终端里敲git rl，输出会清爽很多。这个技巧不是用了什么黑科技，只是把常用参数打包了一下，但确实能减少一些“看到一屏幕信息不想看”的心理抗拒。

6. 从今天开始，养成这几个动作，比会恢复更靠谱

说到底，git reflog是“事后补救”的法宝，但我们在日常开发中完全可以靠几个习惯，从一开始就降低丢失提交的概率。

第一，重要分支及时推送远程。提交一旦推到远程，就不只是你本地的一个对象了。哪怕你在本地把分支删了、reset 了、rebase 了，远程还能捞回来。很多“回不去”的悲剧，本质上是本地独占提交，最后一个救命的引用也被清掉了。所以对我来说，一个分支做完阶段性成果、功能能编译能跑了，第一件事就是 push 到远程建一个备份分支，名字都无所谓，先保住再说。

第二，动手 reset 或 rebase 之前，看一眼 status。我之前反复提到工作区未提交改动会被覆盖，这是 reflog 恢复不了的部分，因为 reflog 只跟踪引用，它不记录“从未被追踪的工作区内容”。养成“先 stash 再动刀”的习惯，能帮你避开最大的一类不确定性。

第三，需要做破坏性操作时，优先用“新建分支 + cherry-pick”而不是“原地重置”。如果你不确定旧提交是否还需要，比较安全的方式并不是git reset --hard HEAD~3，而是：

git branch backup-before-reset git reset --hard HEAD~3

这样即使后续发现还要旧代码，直接切回backup-before-reset，把需要的提交 cherry-pick 过来就行。整个过程完全不需要依赖 reflog 的 90 天期限，因为你给旧状态起了一个长期有效的引用。

从另一个角度想，reflog 的意义其实不只是“找回数据”。它更深远的价值是让你对 Git 的引用模型有更清晰的理解——你知道每次 commit、checkout、reset 到底是怎么改变仓库状态的，你就不再恐惧“操作会弄丢代码”这件事。因为绝大多数情况下，Git 不会主动销毁提交对象，它只是让你暂时看不到它而已。

我自己现在遇到“代码不见了”的情况，已经基本不会慌了，流程大概是：先git reflog看引用轨迹，再git fsck --lost-found找孤儿对象，最后用临时分支或重置把内容捞回来。整个过程熟练以后五分钟内就能搞定。你也完全可以做到，前提是先把今天这篇内容里的命令和原理消化一遍，然后找个测试仓库，真的模拟一次 reset 删除提交，再用 reflog 把它找回来。

纸上得来终觉浅，绝知此事要躬行。Git 这类工具，光看文章和文档是不够的，你必须在真实操作中体会一次“丢了提交 → 心跳加速 → 成功找回”的完整过程，才能建立真正的肌肉记忆。等哪天真在工作里遇到这种情况，你就不是在慌乱中乱敲命令，而是像一个处理过很多次事故的老手一样，翻开 reflog，准确找到那一条记录，敲下恢复命令，对着屏幕淡定地说一句：回来就好。