Git rebase 冲突解决后怎样继续流程

Git rebase 发生冲突后，正确顺序不是重新执行 pull，也不是创建一个 merge 提交，而是：确认当前确实处于 rebase，解决并保存每个冲突文件，暂存这些文件，再运行 git rebase --continue。如果下一个提交又产生冲突，就重复这一组动作，直到 Git 报告 rebase 完成。

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

VS Code 冲突处理文档：https://code.visualstudio.com/docs/sourcecontrol/merge-conflicts

记住一个判断：冲突标记消失只代表文件内容已经编辑完，只有保存、暂存并执行 git rebase --continue，rebase 才会真正向后推进。

先确认 VS Code 停在的是 rebase

打开 VS Code 的“源代码管理”视图后，先不要急着点击提交。冲突可能来自 merge、pull、cherry-pick、stash restore 或 rebase，不同操作的收尾命令不同。最稳妥的入口是打开集成终端执行下面的命令：

# 查看当前分支、正在进行的 Git 操作和冲突文件
git status

# 只查看未暂存差异，确认冲突标记和修改范围
git diff

如果输出中出现类似“rebase in progress”或列出当前正在重放的提交，说明收尾命令应该使用 git rebase --continue。如果看到的是 merge 或 cherry-pick，就不要套用本文的 rebase 命令。

在编辑器里处理每个冲突文件

在“源代码管理”面板的冲突文件列表中逐个打开文件。VS Code 会在冲突区域显示当前内容、传入内容和合并结果等操作入口。选择按钮只是起点，仍要阅读合并后的结果：配置文件的逗号、缩进和字段重复，往往不能靠单个按钮自动判断。

1. 点击冲突文件，定位到 、=======、>>>>>>> 标记。
2. 根据业务意图选择“保留当前”“采用传入”，或直接编辑合并结果。
3. 确认最终内容只保留一份有效代码，并删除所有冲突标记。
4. 保存文件，再回到“源代码管理”面板检查它是否从“冲突”进入待暂存状态。

这里的可见成功条件是：编辑器里不再显示冲突标记，源代码管理面板也不再把文件归为“冲突”。如果文件仍在冲突列表中，先回到编辑器继续处理，不要运行 continue。

先检查差异，再暂存修复结果

解决多个文件时，可以先做一次轻量检查，再统一暂存。它的作用是发现空白字符错误或残留冲突标记，不等于替代测试。

# 检查空白字符错误和常见差异问题
git diff --check

# 暂存已经确认过的单个冲突文件
git add path/to/resolved-file

# 文件较多时，按明确范围暂存，不要把无关修改一并加入
git add path/to/another-file

不要用 git add . 代替核对，除非你已经确认工作区里的其它文件也属于这次 rebase。暂存后再执行一次 git status，确认所有冲突文件都进入“Changes to be committed”或中文界面对应的暂存区域。

运行 git rebase --continue 继续流程

确认全部冲突文件已经保存和暂存后，在 VS Code 集成终端执行：

# 继续重放刚才因冲突暂停的提交
git rebase --continue

Git 可能打开提交信息编辑器。这时保留原提交说明或按团队约定修改后保存并退出，Git 才能继续。也可能出现两种结果：

• 当前提交顺利重放，Git 自动进入下一个提交，命令结束后需要再次查看 git status。
• 下一个提交与当前基线再次冲突，回到上一节继续解决、保存、暂存和执行 git rebase --continue。

当 VS Code 的源代码管理面板不再显示冲突文件，终端也不再提示 rebase 正在进行时，才可以进入最后的验收步骤。

用状态和历史确认 rebase 已结束

成功完成后，建议检查工作区和最近的提交关系。不要只看命令没有报错就直接推送。

# 确认没有 rebase 进程，也没有遗漏的冲突文件
git status

# 查看最近几条提交，确认本地提交已经位于目标基线之后
git log --oneline --decorate -n 8

# 在推送前检查最终差异，避免把无关修改带入提交
git diff HEAD^ HEAD

git status 如果显示工作区干净，说明这次操作没有留下未提交文件；如果还有未提交改动，不要把它自动解释成失败，先判断它是本来就存在的本地修改，还是冲突处理产生的遗漏。

rebase 会改写提交历史。若这些提交已经被其他人基于远程分支继续开发，推送前先和团队确认更新方式；不要为了绕过拒绝盲目强制推送。

什么时候应该放弃 rebase

如果发现基线选错、冲突内容无法判断，或需要先保留当前状态，可以先复制或提交需要保留的独立修改，再退出本次 rebase：

# 放弃当前 rebase，尝试恢复到开始前的状态
git rebase --abort

# 退出后确认 Git 已经不再处于 rebase 中
git status

--abort 会丢弃这次 rebase 过程中已经做出的冲突解决结果，所以不要把它当成“撤销最后一步”的按钮。若只是想跳过当前提交，也可以先确认团队是否允许，再考虑 git rebase --skip；跳过意味着这个提交不会被重放，不应在不了解变更内容时使用。

常见问题

解决冲突后为什么还提示 unmerged paths？

通常是文件虽已编辑保存，但还没有执行 git add。回到状态列表，逐个暂存所有已解决文件。

执行 continue 后再次出现冲突是不是失败？

不一定。rebase 会按顺序重放多个提交，每个提交都可能与新基线发生冲突。只要仍处于 rebase，就重复“解决、保存、暂存、continue”。

能不能点击 VS Code 的提交按钮代替 continue？

界面可能会提供继续当前操作的入口，但判断依据仍是 Git 的状态。遇到不确定的情况，优先在集成终端运行 git status，确认当前操作和下一步命令。

一张表记住收尾动作