【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[拯救成功!]