Git 误操作后的救援：用 reflog 找回 reset --hard 与误删分支的提交

背景

git reset --hard、误删分支、rebase 改乱了历史……这些操作看起来像是把提交“弄丢了”，但多数情况下提交对象仍在仓库里，只是没有分支或标签指向它。本文介绍用 reflog 找回它们的方法，以及哪些情况无法恢复。

一、reflog 是什么

reflog 记录本地仓库中 HEAD 和各分支引用的每一次移动，包括 commit、checkout、reset、rebase、merge 等。它只存在于本地，不会随 push 同步，默认保留一段时间（未被引用的条目默认约 30 天，可达条目约 90 天，由 gc.reflogExpire 等配置决定）。

git reflog
# 或查看某个分支
git reflog show feature/login

输出中每行形如 abc1234 HEAD@{3}: reset: moving to HEAD~2，HEAD@{n} 就是可以回到的位置。

二、场景 1：reset --hard 回退过头

假如执行了 git reset --hard HEAD~3，最近 3 个提交从分支上消失了：

git reflog                # 找到 reset 之前的那一条，例如 HEAD@{1}
git reset --hard HEAD@{1} # 回到 reset 前的状态

更稳妥的做法是先建分支保存，再决定怎么处理：

git branch rescue HEAD@{1}

三、场景 2：误删分支

git branch -D feature/x 删除后，分支上独有的提交没有任何引用，但对象还在：

git reflog                       # 找到删除前该分支最后一次提交的哈希
git branch feature/x <哈希>      # 重新创建同名分支

如果不确定哪个哈希是对的，可以逐个 git show <哈希> 查看提交内容。

四、场景 3：rebase 或 merge 搞乱了历史

rebase 之前的分支末端会记录在 reflog 里，也可以使用 ORIG_HEAD：

git reset --hard ORIG_HEAD

注意：ORIG_HEAD 会被后续的危险操作覆盖，所以出问题后应立刻使用，或者先查 reflog 确认。

五、场景 4：丢了 stash

git stash drop 或 git stash clear 之后，可以用 fsck 找悬空提交：

git fsck --no-reflog | grep 'dangling commit'
git show <哈希>
git stash apply <哈希>

六、无法恢复的情况

• 从未提交过的修改：工作区或暂存区里没有 git add、也没有提交的内容，被 reset --hard 或 checkout -- . 覆盖后，Git 里没有记录，通常无法找回。已经 git add 过的文件，可能还留有 blob 对象，可以尝试 git fsck --lost-found。
• reflog 已过期并被 gc 清理：超过保留期且执行过 git gc 后，对象会被真正删除。
• 换了仓库或重新克隆：reflog 只在原来的本地仓库中。

七、避免再次出事

1. 危险操作之前先建备份分支：git branch backup-$(date +%F)。
2. 用 git reset --keep 或 git stash 代替 --hard，必要时先 git status 确认。
3. 强制推送使用 git push --force-with-lease，避免覆盖他人的提交。
4. 已经推送过的提交，远端或其他同事的本地仓库通常还有副本，也可以从那里找回。

速查