reflog 是什么
Git 在本地仓库里记录 HEAD 与各分支引用的移动历史，这就是 reflog。误 reset、误 rebase、误删分支、误 checkout 覆盖之后，只要提交对象还留在本地仓库里，就能顺着 reflog 找到目标提交并恢复。它只覆盖引用的移动，记录不了从未提交过的改动。
基本信息
| 适用场景 | 本地仓库中误 reset、rebase、删分支、checkout 覆盖后的恢复 |
|---|---|
| 机制 | 记录 HEAD 与分支引用的移动历史 |
| 默认保留 | 约 90 天（由 gc.reflogExpire 等配置决定，可用 git config 调整） |
| 前提 | 提交对象未被垃圾回收清理 |
| 边界 | 未 add/commit 的改动不在覆盖范围；裸仓库默认不写 reflog |
| 相关命令 | git reflog、git branch、git fsck --lost-found、git cherry-pick |
典型使用场景
- 误执行 git reset --hard，丢掉本地未推送的提交
- rebase 结果不如预期，想回到变基之前的状态
- 误删分支后找回分支上的提交
- 误 checkout 覆盖工作区，但内容曾经提交过
- 排查「昨天的提交怎么不见了」这类引用移动问题
恢复流程
恢复流程
# 1) 查看 HEAD 移动历史，找到误操作前的提交
git reflog
# 2) 先建分支锁定现场，避免后续操作或回收把它清掉
git branch rescue HEAD@{2}
# 3) 核对找回的内容是否完整
git log --oneline rescue | head
# 4) 确认无误后再合并或挑选提交回目标分支
git cherry-pick <commit>
# 5) 连引用都找不到时，扫描悬空对象
git fsck --lost-found
# 注意：发现误操作后先别继续操作，多跑一条命令都可能改变 HEADreflog 输出读法
| 字段 | 含义 | 正常/异常 |
|---|---|---|
| HEAD@{n} | 相对序号，n 越大越早 | 用于精确定位误操作前的那个状态 |
| 提交短哈希 | 该时刻 HEAD 指向的提交 | 记下它才能执行恢复 |
| 动作类型 | commit、reset、rebase、checkout、merge 等 | 找到与误操作对应的那一条 |
| 描述文本 | 动作摘要信息 | 描述模糊时要结合时间点核对 |
| 时间表达式 | 也支持 HEAD@{yesterday} 这类写法 | 与实际时间不符要考虑机器的时钟与时区 |
reflog 是本地机制：换一台机器或换一个克隆目录都看不到原来的记录。团队场景下，远端仓库与协作者的副本是最后的兜底。
找回提交后不要再用 reset 硬覆盖当前分支：先建分支或 cherry-pick 到目标分支，确认无误后再决定历史怎么整理。