【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
📚核心原理
- reflog 是什么：Git 的操作日志，记录本地仓库中 HEAD 和分支引用的变化（默认保留 90 天）。
- 为何 rebase 会导致提交丢失：Rebase 会重新构建提交历史，原始提交变成“游离状态”，但并未被立即删除。
- reflog记录默认保留90天，但本地仓库清理操作可能提前删除记录，发现丢失要立即抢救！
🔍操作建议
- 预防措施
# 拉取远程代码时优先使用 merge（安全性更高）
git pull origin main
# 或在 rebase 前备份分支
git branch backup-branch
- 重要操作前打标签
git tag before-rebase
- 理解 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[拯救成功!]