不知道你有没有过这种时刻在 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 commitHEAD 从原来的提交 A 移动到新提交 B这就是一次引用变化reflog 会记一条。你执行git reset --hard HEAD~1HEAD 从 B 移回 A这又是一次引用变化reflog 也记一条。你切分支git checkout devHEAD 从 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 --abortGit 会把当前分支的指针恢复到 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 stashGit 本质上是在创建一个特殊的 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里且未被 gcreflog 的内容就会一直存在。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 --dateiso这个命令会在每条记录后面显示具体的操作时间方便你确认自己大概是在哪个时间点搞丢的提交。办法二配合 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 也没有 stashgit 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 常见“丢提交”场景快速恢复对照表丢失场景关键 reflog 命令推荐恢复方式git reset --hard回退过头git reflog找到 reset 前位置git reset --hard 哈希或新建分支git rebase --abort后分支丢了git reflog查看 rebase 前分支指针git branch 新分支名 reflog中的哈希git branch -D删除未合并分支git reflog找到该分支最后的引用位置git checkout -b 原分支名 哈希git cherry-pick --abortgit reflog查看 abort 前的位置新建分支后 cherry-pick 所需提交git stash clear清了 stashgit reflog show stashgit stash apply stash哈希reflog 被覆盖且对象仍残留git fsck --lost-found将 dangling commit 建分支恢复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 --dateiso --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准确找到那一条记录敲下恢复命令对着屏幕淡定地说一句回来就好。