Git rebase按提交顺序恢复冲突并继续变基的实现方法

Git rebase 进入冲突暂停状态后，不要重新执行一遍变基命令。正确做法是围绕当前暂停的提交完成“定位冲突文件、解决并保存、暂存、继续变基”这一小循环；如果下一提交再次冲突，就按同样顺序继续。下面用一个原创 Git 桌面客户端的界面路径说明操作，命令行只作为动作核对。

官方地址：https://git-scm.com/docs/git-rebase

核心判断是：当前冲突属于哪个提交，解决后是否已经暂存。只有工作区中的冲突标记清掉并进入已暂存状态，Continue rebase 才会推进到下一个提交。

先确认当前暂停在哪个提交

打开 Git 客户端的仓库窗口，在左侧选择当前工作分支，进入顶部的 Branch → Rebase current branch。在对话框中把 main 设为目标分支，点击 Start rebase。发生冲突后，客户端不会自动替你选择内容，而是停在产生冲突的那一个提交。

1. 左侧确认蓝色高亮的是当前分支，目标分支显示为 main。
2. 中央提交图找到带琥珀标记的暂停提交，右侧打开 Conflicts 面板。
3. 先记下冲突文件数量和提交短名，再开始编辑，避免把后续提交的问题混在一起。

等价的命令行检查动作如下。这里的命令用于读取现场，不会自动覆盖你的文件。

# 查看变基是否暂停，以及哪些文件仍未解决
git status
# 查看当前冲突位置附近的提交关系
git log --oneline --decorate --graph -8

在冲突解决器中只处理当前提交

在 Conflicts 面板点击文件名，进入左右两栏或三栏的冲突解决器。左侧代表当前分支改动，右侧代表目标分支改动，中间是待保存结果。不要直接整段接受某一侧：先根据这个提交的目的保留必要代码，再手动合并两侧都需要的配置或函数调用。

1. 点击 Keep current、Keep target 或编辑中间结果；按钮只针对当前冲突块。
2. 搜索并删除 、=======、>>>>>>> 三类冲突标记。
3. 点击 Save file，确认右侧文件状态从 Conflict 变为 Resolved。

如果一个文件包含多个冲突块，必须全部处理后再保存。解决器显示 Resolved 只表示文件没有未处理标记，不等于它已经进入本次提交；下一步还要暂存。

暂存已解决内容并继续变基

回到 Changes 面板，勾选刚才处理的文件，点击 Stage resolved。当冲突文件从 Unmerged 区域移动到 Staged 区域后，再点击顶部的 Continue rebase。客户端会把当前提交应用完成，并尝试处理提交链中的下一项。

# 将已经人工确认的文件加入当前暂停提交
git add path/to/resolved-file
# 让 Git 按原提交顺序继续变基；不要手动新建一个替代提交
git rebase --continue

下一提交再次出现冲突并不代表前一步失败。此时回到“查看当前提交 → 解决全部冲突 → 保存 → 暂存 → 继续”的循环，直到客户端显示完成。

完成后核对提交链和异常回退

完成提示出现后，查看状态栏是否为 Clean，再在提交图中确认当前分支已经位于目标分支之上。若分支有远程副本，rebase 会改写提交 ID，推送前应先和协作者确认，再按仓库约定选择安全的强制推送方式。

如果发现冲突解决方向错误，仍在暂停状态时点击 Abort rebase，或执行下面的命令回到变基前状态。只有确定当前提交本身不应保留时才使用 Skip，不要把 Skip 当成普通的冲突修复按钮。

# 放弃当前整次变基并恢复到开始前的分支状态
git rebase --abort
# 仅在确认当前补丁可以丢弃时跳过这个提交
git rebase --skip
# 完成后再次确认工作区和分支位置
git status
git log --oneline --decorate --graph -8

操作中的两个边界

暂存不等于提交新改动。 rebase 继续时会把暂存结果放回正在重放的原提交，通常不需要手动执行 git commit。如果客户端仍把文件列在 Unmerged 区域，Continue rebase 只会再次提示处理冲突。

完成不等于远程历史自动同步。 本地提交链完成后，先检查测试和提交图；远程分支是否需要强制更新属于协作决策，不能因为本地显示 rebase complete 就直接覆盖他人的新提交。

常见恢复动作速查

按提交顺序恢复的关键不是一次解决所有文件，而是每次只处理 Git 当前暂停的那一个提交，并在“已解决、已暂存、可继续”三个可见状态之间推进。这样既能保留提交语义，也能在下一次冲突出现时快速回到同一套动作。