reflog 是本地 HEAD 和分支指针移动的操作日志，能找回被 reset 或 rebase “隐藏”但未被 GC 清理的提交；它不上传、默认保留 90 天，通过 git reflog 查看历史快照，用 git reset --hard HEAD@{n} 等恢复。
reflog 是什么，为什么它能找回“消失”的提交
Git reflog 记录的是你本地仓库中所有 HEAD（以及分支）的移动历史，不是提交图谱里的“逻辑关系”，而是你真实敲过的每一条命令留下的操作快照。它不随 push 上传，也不被 gc 立即清理，默认保留 90 天（可配）。所以哪怕你 reset --hard、rebase 把分支指针拽走了，那些旧提交只要没被 GC 回收，reflog 就还记着它们在哪。
常见误操作后看不到提交，不是“删了”，是“找不到了”——reflog 就是你的本地操作录像带。
怎么查到那个被 reset 掉的提交
运行 git reflog，你会看到类似这样的输出：
abc1234 HEAD@{0}: reset: moving to HEAD~2
def5678 HEAD@{1}: commit: add user profile page
ghi90ab HEAD@{2}: checkout: moving from feature/login to main
注意看 HEAD@{n} 这一列，数字越大越早；右边动作描述帮你定位上下文。比如你刚执行了 git reset --hard HEAD~1，那你要找的提交大概率在 HEAD@{1} 或更早的位置。
Git Log Summary
下载
生成Markdown格式的Git提交摘要报告。适用于需以Markdown输出仓库详细统计的场景。输出包含项目信息、分支、提交统计、作者统计、最近提交记录及提交类型统计等，均以Markdown呈现。
- 用
git reflog -n 20查最近 20 条，避免刷屏 - 加
--date=iso可辅助判断时间顺序：git reflog --date=iso - 如果记得大致提交信息，可以用
git reflog | grep "profile"快速过滤 -
HEAD@{0}是当前状态，HEAD@{1}是上一次 HEAD 所指，别反着数
怎么把提交“捞回来”：reset、cherry-pick 还是 merge
找回 ≠ 一定要恢复原分支。根据你当前状态和目标选择最安全的方式：
- 如果只是想让当前分支回到某个 reflog 位置：
git reset --hard HEAD@{2}（⚠️会丢弃工作区和暂存区未提交的改动） - 如果当前有未提交修改，不想丢，改用
git cherry-pick abc1234（把某次提交单独应用过来） - 如果那个提交属于另一个已删除的分支，先用
git branch recover-branch abc1234创建新分支指向它，再决定怎么合并 - 不要直接
git reset --hard abc1234（不带@{n}），除非你确认这个哈希确实还在对象库——reflog 里显示的哈希可能已被 GC 清掉
reflog 不是万能的：三个容易忽略的限制
reflog 只存在于本地，别人 push 不来，你也 push 不出去。它救不了远端丢失，也救不了彻底被 git gc --prune=now 干掉的对象。
- 默认只记录 90 天内的操作，老项目或长期闲置分支，
HEAD@{100}可能已不存在 - 某些 Git GUI 工具（如 VS Code 内置 Git）执行操作时可能不触发 reflog 记录，优先用命令行复现关键步骤
-
reflog不记录git clean或文件系统级删除，它只管引用指针移动，不管磁盘文件
真正难的不是“怎么找回”，而是你得记得自己干过什么、大概什么时候干的——reflog 不记语义，只记动作和时间戳。
