【Git】reflog实战：找回丢失的提交

📘 问题背景：

当你在本地提交了代码（commitA 和 commitB），执行 git pull --rebase 与远程仓库同步时，可能会发现本地的两个提交“消失”了。这是因为 rebase 操作重写了提交历史，导致本地提交被“覆盖”。此时，git reflog 是你的关键救援工具。关键步骤解析1

1️⃣.现象复现

# 本地提交记录
git commit -m "新增登录页动画"     # commitA
git commit -m "修复表单校验BUG"   # commitB
git pull --rebase origin main     # 同步远程代码

执行后，git log 中仅显示远程最新代码，本地提交 commitA/B 不再可见。

2️⃣. 使用 reflog 定位提交

git reflog 记录了所有 HEAD 指针的移动轨迹（包括提交、重置、合并等操作）：

git reflog
# 输出示例：
e3f5a1a (HEAD -> main) HEAD@{0}: rebase finished
d28bcd5 HEAD@{1}: commit: 修复表单校验BUG  # 消失的 commitB
a1b2c3d HEAD@{2}: commit: 新增登录页动画  # 消失的 commitA

3️⃣. 恢复提交的两种方式

方案一：直接重置分支

# 找到 rebase 前的提交点（如 HEAD@{2}）
git reset --hard HEAD@{2}
# 此时 commitA/B 会重新出现在分支历史中

方案二：选择性迁移提交（推荐）

# 1. 从 reflog 中复制 commitA/B 的哈希值（如 a1b2c3d 和 d28bcd5）
# 2. 将提交应用到当前分支
git cherry-pick a1b2c3d d28bcd5
# 3. 强制推送到远程（若需覆盖）
git push -f origin main

📚核心原理

1. reflog 是什么：Git 的操作日志，记录本地仓库中 HEAD 和分支引用的变化（默认保留 90 天）。
2. 为何 rebase 会导致提交丢失：Rebase 会重新构建提交历史，原始提交变成“游离状态”，但并未被立即删除。
3. reflog记录默认保留90天，但本地仓库清理操作可能提前删除记录，发现丢失要立即抢救！

🔍操作建议

1. 预防措施

# 拉取远程代码时优先使用 merge（安全性更高）
git pull origin main
# 或在 rebase 前备份分支
git branch backup-branch

2. 重要操作前打标签

git tag before-rebase

3. 理解 rebase 的风险

场景	风险等级	应对方法
多人协作的分支	高危	避免使用 rebase，优先使用 merge
本地未推送的提交	中风险	执行 rebase 后检查提交完整性

🕵️‍♂️总结

1.git reflog 是 Git 的“安全网”，可回溯几乎所有本地操作。
2.在 rebase/force push前，建议备份当前状态。

🌈 彩蛋：可视化救援地图

graph LR
  A[操作前] -->|rebase风暴| B[commit消失]
  B --> C{启动reflog}
  C --> D[定位坐标]
  D --> E[建立救援分支]
  E --> F[cherry-pick搬运]
  F --> G[拯救成功!]