真实场景：一次用力过猛的push，40个提交全没了

事情发生在周四下午，我刚改完一个紧急Bug，准备合入develop分支。同事A说他在我的分支上做了小改动，让我先rebase拉最新代码。我执行了

git pull --rebase origin develop

结果冲突来了。我在IDE里手动合并了几个文件，然后

git add .
git rebase --continue

中途有个文件忘记解决冲突就continue了，导致合并结果乱七八糟。我更糊涂地执行了

git reset --hard HEAD~3

然后突然发现——我过去两周的40个提交全部消失了。大脑瞬间空白。

后来我冷静下来，用git reflog救了回来。但这经历让我决定把Git救援的干货系统整理出来。本文针对两类最致命问题：Git冲突解决失败导致提交丢失和误操作（reset、push --force）导致分支提交丢失。直接给方案，不废话。

问题分析：冲突为什么会导致提交丢失？

Git冲突本身不会丢提交，但人的操作会。常见死法：

• rebase冲突解决不当：没看清合并结果就continue，最后rebase完成但代码不对，于是reset –hard回退，结果把rebase之前的提交也丢了。
• git push –force覆盖远程：合作分支上有人push了旧版本，你发现冲突后直接force push，把别人提交抹掉。
• git reset –hard 误删：想回退一个commit，结果没加参数直接硬重置。
• git branch -D 误删分支：删除的分支里还有未合并的提交。

原理层面：Git的提交一旦被创建，就永恒存在，直到被垃圾回收（git gc）。你只是丢失了引用（分支、HEAD等）。只要引用丢失，提交就变成“悬空对象”，但文件还在.git/objects目录里。解决方案就是重新找回这些悬空对象的引用。

方案一：用git reflog精准恢复（最强保命技）

原理

git reflog记录了HEAD指针的所有移动历史，包括reset、checkout、commit、merge等操作。默认保留90天。每次操作都会生成一条记录，格式：HEAD@{index}。你可以直接切到那个状态。

步骤（实战）

# 第一步：查看reflog，找到丢失提交前的状态
git reflog --date=local | head -20

输出示例：

1234567 HEAD@{2024-01-15 14:32:45}: commit: fix: login page bug
abcdef0 HEAD@{2024-01-15 14:30:00}: reset: moving to HEAD~3
9876543 HEAD@{2024-01-15 14:28:12}: rebase finished: returning to refs/heads/feature/login
...

找到你想恢复的那条commit记录（比如1234567）。然后：

# 第二步：创建临时分支指向该commit，避免影响当前工作
git branch rescue-branch 1234567

# 或者直接切过去看代码
git checkout 1234567

如果只想恢复部分提交，可以用cherry-pick：

# 第三步：从rescue分支cherry-pick需要的commit到当前分支
git checkout develop
git cherry-pick 1234567 89abcde

注意事项

• reflog只在本地仓库有，远程克隆看不到。所以commit丢了不要删本地仓库。
• 如果reflog也被清空（比如执行了git reflog expire --expire=now），可以用git fsck找悬空对象。

# 备用：用fsck找到所有未引用的commit
git fsck --lost-found
# 会输出类似 dangling commit 1234567...
# 然后可以 git show 1234567 查看内容
# 或者 git merge 1234567 合并回来

方案二：用cherry-pick手动重构提交历史（适用于复杂冲突场景）

当冲突太多，rebase中途中断且你不想冒险时，可以用cherry-pick逐个挑出正确的提交。

场景：rebase冲突解决过程中，你发现某个合并结果不对，但已经continue了多步。

# 先查看reflog，找到rebase开始前的原始分支位置
git reflog
# 比如原始分支在HEAD@{10}
# 硬重置回那个点
git reset --hard HEAD@{10}

然后重新rebase，但这次用交互模式，逐个处理冲突：

git rebase -i origin/develop

或者完全手动cherry-pick：

# 列出你要cherry-pick的commit列表（用git log查看原始分支）
git log --oneline original-branch..target-branch
# 假设有5个commit: a b c d e
# 逐个处理，每个都可能产生冲突
git cherry-pick a
# 如果冲突，解决后 git add . && git cherry-pick --continue
git cherry-pick b
git cherry-pick c
...

如果冲突很多，每次解决后建议git commit而不是continue，这样可以保留冲突解决记录。但cherry-pick默认会用原commit信息，注意修改。

方案对比：reflog vs cherry-pick

完整代码实现：一个自动化救援脚本

我写了个bash脚本，可以一键扫描丢失的提交并列出可恢复选项。工具版本：Git 2.40+，bash 5.0+。

#!/bin/bash
# git-rescue.sh — 救援丢失的Git提交
# 使用方法：bash git-rescue.sh

set -euo pipefail

echo "=== Git 提交救援工具 v1.0 ==="
echo "1. 检查reflog..."
if git reflog show -1 &> /dev/null; then
    echo "   reflog可用，最近20条记录："
    git reflog --date=local | head -20
else
    echo "   reflog不可用或为空，尝试git fsck..."
fi

echo ""
echo "2. 搜索悬空对象..."
dangling=$(git fsck --lost-found 2>/dev/null | grep "dangling commit" | awk '{print $3}')
if [ -z "$dangling" ]; then
    echo "   未发现悬空commit。"
else
    echo "   发现悬空commit："
    for commit in $dangling; do
        echo "   - $commit $(git log --oneline -1 $commit 2>/dev/null || echo '无法读取')"
    done
fi

echo ""
echo "3. 建议操作："
echo "   - 如果想通过reflog恢复，运行: git branch rescue "
echo "   - 如果想查看某个悬空commit的内容，运行: git show "
echo "   - 恢复后建议立即创建分支，防止gc清理"

保存为git-rescue.sh，chmod +x后运行。脚本会展示reflog和fsck结果，输出示例：

=== Git 提交救援工具 v1.0 ===
1. 检查reflog...
   reflog可用，最近20条记录：
   abc123 HEAD@{2024-01-15 14:32:45}: commit: fix: login page bug
   def456 HEAD@{2024-01-15 14:30:00}: reset: moving to HEAD~3
   ...
2. 搜索悬空对象...
   发现悬空commit：
   - 789abc 2024-01-10 fix: typo
   - 012def 2024-01-09 feat: add retry
3. 建议操作：
   - 如果想通过reflog恢复，运行: git branch rescue abc123
   - ...

效果数据与压测

我在一个模拟仓库中测试了恢复能力：仓库包含200个提交，随机删除分支、执行reset --hard、rebase --continue失败等操作。测试环境：Git 2.42.0，CentOS 7，ext4文件系统。

结论：reflog是最快最可靠的恢复手段，只要没执行git gc --prune=now，基本都能救回来。cherry-pick适合有选择性地恢复部分提交，但速度慢，容易遗漏依赖。

避坑指南：我踩过的5个坑

1. 坑一：reflog不是万能的
   如果你在执行误操作后又执行了git reflog expire --expire=now，reflog会清空。但别慌，还有git fsck。不过fsck只能找到悬挂的commit，如果commit被包含在另一个commit树里（比如作为未合并的树对象），也能找到。但不要依赖reflog，养成习惯：每次重要操作前先打标签。
2. 坑二：cherry-pick顺序依赖问题
   有一次我在cherry-pick时漏了中间一个commit，结果后面commit的diff基于前面修改，导致冲突灾难。建议用git log --graph看清楚提交顺序，或者直接使用git range-diff验证。
3. 坑三：git fsck --lost-found 会创建一个 .git/lost-found 目录
   如果你忘了清理，里面可能积累大量无用对象，导致.git体积膨胀。我见过有人.git目录达到20GB。定期运行git fsck --unreachable并清理。
4. 坑四：远程force push后，其他协作者的本地reflog会被覆盖吗？
   不会。reflog是本地操作记录，即使远程分支被force push覆盖，你本地的reflog依然保留原始commit。所以不要删本地仓库，从本地reflog恢复后再push正确的版本。
5. 坑五：Windows路径大小写导致reflog中commit hash显示不全
   在Windows上使用git bash时，如果路径大小写不匹配，可能导致git reflog部分提交hash变成^...。此时用git reflog --all或者git log -g可能得到完整hash。

最后一条铁则：在跑任何破坏性命令前，先用git stash或git branch backup创建备份。同事A后来跟我说：“我每次rebase前都先打个tag，成了。” 我补一句：“标签也要push到远程，否则本地磁盘坏了全完。”