rebase 出错后怎么恢复

学完这篇你会掌握什么

• 理解 rebase 出错后怎么恢复 的核心作用和适用场景
• 掌握 rebase 出错后怎么恢复 的基本用法和常用参数
• 当 rebase 过程中冲突、提交丢失或结果不对时，先停止继续改写历史，再用 reflog、abort 和救援分支恢复可控状态。
• 理解 先记住：rebase 出错时最怕继续慌着重试 相关的概念
• 掌握 先分清两类场景 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

先想一个问题

你刚刚在 Git 里做了一个操作，结果发现不是你想要的效果——甚至可能弄丢了提交。这种情况不是第一次了，你想建立一套可靠的方法来应对各种误操作场景。

先记住：rebase 出错时最怕继续慌着重试

rebase 前（安全状态）

main

ABCD

feature

BEF

恢复：git reflog / git branch rescue

rebase 后（可能有问题）

main

ABCD

feature

DE'F'

很多人一看到冲突、提交顺序不对，或者觉得某个提交不见了，就继续 rebase、reset、checkout 来回试。
真正更稳的做法是先停下，先把“出问题前的入口”保住。

先分清两类场景

场景一：rebase 还没结束

这时 Git 通常会明确告诉你可以：

• git rebase --continue
• git rebase --skip
• git rebase --abort

如果你已经不确定现在的中间状态对不对，优先考虑 --abort，回到 rebase 之前再重新判断。

场景二：rebase 已经完成，但结果不对

这时不要再假设“可能只是我看错了”。
先直接看 reflog，确认 rebase 前分支原本在哪里。

git reflog

常见做法是先用 rebase 前的位置建一条救援分支：

git switch -c rescue/pre-rebase HEAD@{3}

为什么 rebase 后“提交像丢了”

因为 rebase 的本质不是搬运原来的提交对象，而是基于新基底重放一组新的提交。
这意味着：

• 提交 ID 会变
• 历史关系会变
• 旧提交对象可能暂时还在，但分支名不再指向它们

所以很多“丢了”的感觉，其实是“名字改指向了新提交”。

一个保守恢复流程

git status
git log --oneline --graph --decorate -n 30
git reflog
git switch -c rescue/pre-rebase <old-commit>

然后再决定是：

• 直接回到 rebase 前
• 只摘回部分提交
• 还是重新做一遍更干净的 rebase

什么时候该直接 --abort

如果你满足下面任一条件，通常优先 git rebase --abort：

• 还在 rebase 过程里
• 你已经分不清自己解决的是哪一个冲突
• 你不确定 skip 会不会漏掉重要提交
• 这次 rebase 本来就只是本地整理，不值得冒险继续赌

什么时候该先建救援分支

如果 rebase 已经结束、历史已经改写、而且你想对比“改之前”和“改之后”，那就先建救援分支。
它的价值不是马上修好，而是先把证据和旧位置保住。

一个实用原则

rebase 失败时，目标不是立刻“修到能 push”，而是先恢复到“你还能解释现在发生了什么”的状态。
能解释，后面才安全。

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• 误用 git clean 后的恢复
• reset 过头后怎么恢复
• cherry-pick 挑错提交后的恢复