Git rebase 中途出现冲突时怎么安全回到开始前

Git rebase 进行到一半遇到冲突，想安全回到开始前，核心命令是 git rebase --abort。它会取消当前变基，把当前分支的 HEAD、索引和工作区恢复到变基开始时的状态；但执行前仍应先确认仓库确实停在 rebase 中，不要把普通未提交改动误当成变基现场。

官方文档：https://git-scm.com/docs/git-rebase

步骤一：确认变基仍处于暂停状态

在项目根目录打开集成终端，先看状态。冲突时 Git 通常会提示当前正在 rebase，并列出待解决文件。为了确认停在哪个补丁，可以再查看当前 patch。

# 先确认仓库状态，避免在普通工作区误执行 abort
git status
# 查看当前暂停的 rebase 补丁，便于判断是否真的卡在冲突提交
git rebase --show-current-patch

如果输出没有 rebase 进行中的提示，先停下来检查分支和未提交改动。只有确认状态属于本次变基，才进入下一步。

步骤二：执行 git rebase --abort 取消当前变基

在同一个项目根目录、同一个集成终端中输入下面的命令。它的作用是取消整个未完成的 rebase，而不是只撤销当前文件的冲突标记。

# 放弃本次未完成的变基，回到变基启动前的分支状态
git rebase --abort

成功后，终端一般会回到普通命令提示符。这里的“回到开始前”指分支尖端和 Git 管理的工作状态恢复，不代表你后来新建的未跟踪文件会自动消失。

步骤三：检查分支、索引和工作区是否恢复

取消命令返回后不要立刻重新 rebase。用三项检查确认现场已经收干净：状态看流程是否结束，差异检查找残留问题，日志确认 HEAD 是否回到了预期位置。

# 确认不再处于 rebase，也确认是否仍有未提交文件
git status
# 检查差异中的空白错误，排除冲突处理留下的脏内容
git diff --check
# 查看最近提交和当前分支标记，核对 HEAD 是否回到预期位置
git log --oneline --decorate -n 4

步骤四：分清 abort、quit 和 skip 再重新操作

三个选项不能混用。想完整回到变基前用 --abort；冲突已解决、准备继续应用后续提交用 --continue；当前补丁确定不需要才用 --skip。--quit 只停止 rebase，HEAD、索引和工作区保持当前样子，适合你想保留现场再人工处理的情况。

# 已修复冲突并用 git add 标记文件后，继续变基
git rebase --continue
# 只有确认当前提交可以舍弃时才跳过它
git rebase --skip
# 只退出流程但保留当前 HEAD、索引和工作区
git rebase --quit

如果这条分支已经推送给别人，重新 rebase 前还要确认团队是否接受历史改写；若只是本地尝试，先保留必要差异并记录变基前的提交号，恢复会更稳。

相关问题

git rebase --abort 会删除未跟踪文件吗？

不要把它当作清理命令。未跟踪文件是否保留取决于它们是否被其他操作覆盖；重要文件应先移出工作区或单独备份。

为什么 abort 后 ORIG_HEAD 看起来不对？

官方手册说明，后续执行 reset 等会改变 ORIG_HEAD 的命令后，它不保证仍指向原提交；需要回看当前分支 reflog。

冲突解决后应该用 continue 还是重新 rebase？

已经确认每个冲突文件、执行 git add 并保留当前提交内容时，用 git rebase --continue；不确定解决结果时先 abort，再整理后重新开始。