Git解决本地commit丢失问题_Git fsck与reflog恢复实战

先说一个核心判断：本地 commit 丢了，只要还没被 git gc 清理掉，基本都有办法找回来——问题的核心不在于能不能，而在于从哪找、怎么确定找对了。

用 git reflog 找最后一次 HEAD 指向的提交

这是最快捷、也最常用的方式，特别适合刚误删分支、git reset --hard 敲错目标、或者切错分支导致提交突然消失的情况。Git 默认保留 reflog 30 天，只要没有手动清理过 .git/logs/ 目录，这些操作记录就还在。

操作上注意几点：

• 运行 git reflog，输出里会出现类似 abc1234 HEAD@{0}: reset: moving to HEAD~1 或 def5678 branch-name@{2}: checkout: moving from main to branch-name 这样的信息
• 重点看带 @{n} 的条目，尤其是那些你还能回忆起操作时间、分支名或关键词（比如 “checkout”、“reset”、“commit”）的那一行
• 用 git show abc1234 来确认内容：这到底是不是你要找的文件？作者和时间对不对？父提交的链条是否连续？
• 千万别一时手快直接 git reset --hard，稳妥的做法是先 git branch recovered-branch abc1234 打个分支保底，后续再决定怎么合并

用 git fsck --lost-found 扫描 dangling commit

当 reflog 已经被清空，或者你压根没留意过操作历史时，那就得靠 Git 的对象数据库本身了。Git 不会立刻删除那些孤立提交（dangling commit），它们依然躺在 .git/objects 里，只是没有任何引用指向它们。

操作要点包括：

• git fsck --lost-found 的输出里，只关注 dangling commit 那一类行，别去管 tree 或 blob（除非你明确在找单个文件）
• 每一个 dangling commit 的哈希都值得查一遍：先用 git log --oneline -n 3 看最近几次提交，再用 git show --stat 看具体改了哪些文件
• 如果目标提交是某个功能的起始点，它很可能没有父提交（git show 输出里没有 parent 字段），这种提交要优先核对
• 恢复时别急着新建分支，用 git cherry-pick 往现有分支里补提交会更安全，能避免引入意外的祖先链

确认恢复的是完整提交，不是半截状态

不少人找回哈希后直接 git reset --hard，结果发现文件少了几条，或者某次冲突解决被覆盖了——问题就在于，游离状态（detached HEAD）下做的提交本身不自动归属任何分支，而 fsck 找到的也可能只是中间状态。

验证上给几个建议：

• 用 git log --all --oneline --graph --simplify-by-decoration 查看所有引用关系，确认新分支是否真正“接上”了原分支的路径
• 对关键文件单独跑一次 git log --all --oneline -p -- ，比对修改的行号和上下文，防止 cherry-pick 时漏掉部分 hunk
• 如果原分支包含 merge 提交，要注意 git fsck 找到的 dangling commit 很可能只是其中一个 parent，得用 git show 查 Merge: 行，才能还原完整的拓扑结构

reflog 是第一道防线，fsck 是兜底的手段。但真正容易被忽略的是：恢复之后别急着推送，先跑一次 git diff ..recovered-branch 对比净变更，尤其当原分支上还有其他人提交时——强行 push -f 很可能会覆盖别人的工作。