- 正在处理 reset、rebase、删分支事故的人
Command Reference
git reflog
查看引用移动历史，是 reset、rebase、误删分支等恢复场景里最常用的自救命令之一。
- 知道 reflog 记录的是引用位置变化
- 愿意先查位置再动分支
- 把 reflog 当永久保险箱
- 看到旧位置后直接覆盖原分支而不先建救援分支
数据 / 性能事实
- 90 daysdefault reflog expiry for reachable entries; 30 days for unreachable (gc.reflogExpireUnreachable)出处: git-reflog(1) / git-gc(1) official manual
关键引语
The reflog records when the tip of branches and HEAD were updated in the local repository; it is not transferred across clones and is pruned after 90 days by default.
引用与延伸阅读
- Git reflog [官方]
- Git Internals Git References [书籍]
学完这篇你会掌握什么
- 理解 git reflog 的核心作用和适用场景
- 掌握 git reflog 的基本用法和常用参数
- 查看引用移动历史，是 reset、rebase、误删分支等恢复场景里最常用的自救命令之一。
- 理解 为什么它特别重要 相关的概念
- 掌握 常见写法 相关的操作
- 知道在什么场景下使用该命令，什么场景下避免使用
git reflog 记录的是引用移动历史，而不是普通提交历史。很多恢复操作首先要看的不是 git log，而是 reflog。
先想一个问题
你正在 Git 仓库里工作，遇到了一个具体的操作需求——但你不确定用哪个命令、用哪个参数最合适，也不知道这个命令到底能做什么、不能做什么。
为什么它特别重要
当你做了这些操作后：
reset --hardrebasepull- 删除或改写分支
旧提交未必立刻消失，但你可能失去了“当前分支名”。这时 reflog 常常还能告诉你原来在哪里。
常见写法
git reflog
git reflog show HEAD
git reset --hard HEAD@{1}
git checkout -b rescue HEAD@{2}
实战思路
- 先用
git reflog找到误操作前的位置 - 再决定是新建救援分支，还是直接 reset 回去
位置历史
HEAD@{3}HEAD@{2}HEAD@{1}当前 HEAD
恢复动作
rescue/recover
和 git log 的区别
git log看的是提交图git reflog看的是引用曾经指向过哪里
所以 reflog 更像“位置历史”，不是“协作历史”。
风险提示
reflog 不是永久保险箱。随着时间推移和垃圾回收，过旧且不可达的对象可能被清理。所以出问题后越早处理越稳。
这条命令在流程里解决什么问题
git reflog 是一个纯只读的诊断工具，不修改任何提交或引用。它记录的是引用曾经指向过哪些位置，是恢复误操作后最重要的自救工具。它不会重塑历史，但能帮你找到历史被改之前的位置。
典型用例
- 执行
reset --hard后后悔了，用git reflog找到 reset 前的位置。 - 误删分支后，用 reflog 找到旧提交，重新建分支接住它。
- rebase 后发现历史不对，用 reflog 回到 rebase 前的状态。
- 用
HEAD@{N}语法直接引用 reflog 中的旧位置，比如HEAD@{1}表示上一个 HEAD 位置。
图例理解
引用名称（HEAD 或分支名）
引用移动时间线旧位置 hash操作描述
reflog 是纯只读操作，不会影响仓库历史。它是本地记录，不会被 push/fetch 同步。
特殊情况与边界
- reflog 是本地记录，不会被 push 或 fetch 同步到远端。每个人的 reflog 是独立的。
- reflog 条目有保质期：默认 unreachable 的引用保留 30 天，reachable 的保留 90 天。
git gc会清理过期条目。 git reflog expire --expire=now --all可以强制清理，但这是不可逆的。git reflog delete可以删除特定条目，但通常不需要手动管理。- 恢复操作的最佳实践：先用
git checkout -b rescue/...接住旧位置，再决定是否 reset。
跟着做一遍
这组练习的重点不是把仓库弄乱，而是体验“位置变了但对象可能还在”的恢复思路。
git switch -c lab/reflog-demo # 做两次提交 # 然后执行一次 git reset --hard HEAD~1跟着做
- 运行 `git reflog`，找到 reset 前的 HEAD 位置。
- 先用 `git checkout -b rescue/reflog HEAD@{1}` 把旧位置接住。
- 再用 `git log --oneline --graph --decorate --all` 对照现状。
- 你会看到 HEAD 的移动记录仍然保留在 reflog 里。
- 旧提交常常并没有立刻消失，只是当前分支不再指向它。
- 先建救援分支通常比直接 hard reset 更稳。
- 如果还没确认旧位置，就不要连续多次 reset 或 rebase。
- 不要把 reflog 当永久保险箱，出问题后越早接住旧位置越稳。
- 如果恢复动作会影响共享分支，先判断影响面再改引用。
给你的练习
- 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
- 尝试该命令的不同参数选项，对比输出结果的差异
- 模拟一个需要使用该命令的实际场景，完整走一遍操作流程
延伸阅读
沿着同一主题继续深入：