Git rebase 冲突后怎么继续，什么时候该 abort

运行 git rebase main 后停在冲突处，最容易误操作的地方是连试几个命令：先 skip，再 reset，最后发现某个提交没有了。rebase 在逐个重放提交；先弄清当前停在哪一个提交，再决定它应该怎样保留。

先看状态，别急着选一边

git status
git rebase --show-current-patch
git diff --name-only --diff-filter=U

这些命令分别帮助确认是否处于 rebase、当前重放的补丁和仍未解决的文件。先打开冲突块，结合两边代码的用途判断。rebase 场景中的 ours 通常是已经变基到的新基线一侧，theirs 是正在重放的工作提交；不能沿用“ours 永远是我的功能代码”这种记忆。

若这次涉及大量冲突，先把当前改动另存，尤其是冲突处理中手动新增的内容。备份不要只保存冲突标记里的几行，还要考虑新文件与未跟踪文件。

保留当前提交并继续

解决冲突后，只暂存已经确认的文件：

git add path/to/resolved-file
git diff --cached
git rebase --continue

路径需要换成实际文件；有多份文件时逐一处理。git diff --cached 用来确认将进入提交的内容，没有必要用 git add . 把无关临时文件也带进去。编辑器弹出提交信息后，检查说明是否仍准确。

后面还有提交时，rebase 可能再次停住。完成一轮冲突不表示整个过程结束，以 git status 为准。变基完成后运行与改动相关的测试，再看提交顺序和差异；编译成功也不证明每个原提交的意图都保留下来了。

skip 会跳过这个提交

git rebase --skip 用于跳过当前正在重放的提交。补丁已经在新基线中存在，或者你明确决定放弃它时，才适合这样处理。它不会自动理解“保留我的功能、略过冲突部分”。

如果提交变空，先看它的变化是否已经被前面的提交包含。不能仅为了消掉报错就 skip；有意保留空提交等行为还受变基选项影响，应按实际任务判断。

想退出，用 abort

git rebase --abort

它结束变基，并将 HEAD 恢复到开始前的位置。冲突期间追加的手动编辑未必值得丢掉，所以退出前先保留需要的文件或补丁。--quit 与 --abort 也不同：quit 结束变基流程，但不按 abort 的方式恢复 HEAD、索引和工作树，别把两者当同义词。

个人未共享的分支可以更自由地整理；已经被别人基于其开发的分支，变基会改写提交标识，应先协调。不要用强制推送掩盖尚未确认的冲突结果。

各选项的准确行为见 Git rebase 文档。如果提交位置已经找不到，先按 reflog 恢复方法建立恢复分支，再比较内容。