reflog是git本地记录head及分支引用变更的操作日志，不依赖远程、不同步、默认保留90天，只要提交未被gc清理，就能通过head@{n}或分支reflog条目找回其sha值。
reflog 是什么，为什么它能找回“消失”的提交
Git 的 reflog 记录的是你本地仓库中所有引用（主要是 HEAD）的移动历史，每执行一次 checkout、reset、merge、rebase 等操作，都会在 reflog 里留一条痕迹。它不依赖分支指向，也不受远程同步影响，是 Git 本地最可靠的“操作回溯日志”。只要提交对象还没被 GC 清理（默认 30 天内），就能通过 reflog 找到它的 SHA。
常见误删场景包括：git reset --hard HEAD~1 后发现删错了、git rebase -i 误删某条 pick 行、git push --force 覆盖后本地也跟着重置了、甚至 git checkout 切错分支又做了新提交导致原分支指针偏移。
怎么查 reflog 并定位目标 commit
运行 git reflog 就能看到最近几十条 HEAD 移动记录，格式类似：abc1234 HEAD@{0}: reset: moving to HEAD~1。关键信息是 HEAD@{n} 这个索引和右边的操作说明。
-
git reflog默认只显示HEAD的日志；想看某分支（比如main）的独立 reflog，用git reflog show main - 如果记不清具体时间或操作，加
--date=iso或--all（显示所有引用的 reflog）辅助排查 - 目标 commit 通常出现在“删除操作”前一条：比如你执行了
reset --hard HEAD~1，那想找的提交大概率是HEAD@{1}或HEAD@{2} - 确认 commit 内容是否正确？直接
git show HEAD@{1}或git log -1 --oneline HEAD@{1}
找回提交的三种常用方式
找到目标 HEAD@{n} 或对应 SHA 后，根据当前需求选择恢复方式：
- 想把当前分支指针退回去（比如还原被
reset掉的提交）：git reset --hard HEAD@{1}（慎用，会丢弃之后的新提交） - 想把那个提交“捡回来”但不改变当前工作区（比如只是补漏）：
git cherry-pick abc1234（用reflog查到的 SHA） - 想新建一个分支指向它，安全查看或后续合并：
git branch recover-branch abc1234，再git checkout recover-branch
注意：git reset --hard 会重置工作区和暂存区，如果当前有未提交修改，先 git stash；cherry-pick 可能产生冲突，按常规解决即可。
reflog 不见了或找不到提交怎么办
reflog 是本地存储，默认只保留 90 天（gc.reflogExpire）或 30 天（gc.reflogExpireUnreachable），且只记录“可达”操作。以下情况可能导致失效：
- 手动执行过
git gc --prune=now，强制清理了所有不可达对象和旧 reflog 条目 - 该提交从未被任何引用（分支/标签/HEAD）指向过，比如只存在于
git add后没commit就关了终端，那它根本不会进 reflog - 你在别的 clone 仓库里操作，而 reflog 不随
git push/pull同步——它只存在于你本机 - 某些 IDE 或 GUI 工具（如 VS Code Git 插件）可能调用底层命令但不触发 reflog 记录，建议关键操作后手动跑一遍
git reflog确认
reflog 不是保险箱，它只是 Git 给你留的一条“操作草稿线”。真正防丢，得靠及时推送到远程、合理打标签、以及别对未备份的分支狂用 --force。
