Git rebase 冲突怎样保留两边文件片段

Git rebase 停在冲突时，不要直接把整份文件选成“当前”或“传入”。先打开冲突文件，保留真正需要的上游片段和当前分支片段，删除冲突标记，再暂存文件并继续变基。这里最容易踩坑的是：在 rebase 里，Git 文档所说的 ours 通常是已经重放到上游之上的结果，theirs 是正在被重放的当前分支提交，和直觉里的 merge 两边可能相反。

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

下面用一个原创界面说明图展示冲突块的判断位置，再用第二张图展示暂存和继续后的状态。图片是操作示意图，不是实际软件截图。

• 先识别冲突文件和当前正在重放的提交。
• 按冲突块合并两边内容，不要盲目选择整文件。
• 删除 、=======、>>>>>>> 后再暂存。

先确认 rebase 停在什么位置

打开项目的 Git 图形客户端或编辑器中的版本控制面板，先看冲突文件列表和“正在重放的提交”。如果习惯命令行，也可以执行：

# 查看当前变基状态，确认冲突文件和待重放提交
git status

# 查看当前暂停的补丁，帮助判断这次提交想改什么
git rebase --show-current-patch

界面上通常会出现“冲突文件”“当前补丁”或类似状态。不要把这个状态当成普通合并：rebase 是把当前分支的提交逐个重放到上游分支上，所以 ours 与 theirs 的含义需要结合官方说明判断。

在一个冲突块中保留两边内容

打开冲突文件后，会看到三段边界标记。上方片段属于一侧，分隔线下面属于另一侧。真正需要保留两边时，不要点击“全部接受一侧”，而是把两段有用内容手动组合，并删除三行标记。例如配置文件一边新增了超时字段，另一边新增了重试字段，最终文件可以同时保留两个字段，但要检查缩进、逗号和重复键。

>>>>>> feature/transport

# 合并后的示意结果：保留两边有价值的字段
timeout: 5s
retry: 3

如果只想整体采用某一侧，可以在界面中选择对应的“保留上游”或“保留当前提交”动作；使用命令时可对未合并路径执行 git restore --ours 文件 或 git restore --theirs 文件。但是 rebase/pull --rebase 中这两个名字可能与直觉相反，确认上下文后再用。

暂存解决结果并继续变基

保存文件后，在版本控制面板中确认冲突标记已经消失，再点击“暂存”或“标记为已解决”。命令行对应的是：

# 把已经人工合并的文件放入暂存区，声明该冲突已处理
git add path/to/config.yml

# 继续重放后续提交；如果又出现冲突，重复同样的判断
git rebase --continue

# 变基完成后，查看提交图和工作区是否干净
git status

图形界面中应能看到文件从“冲突”移动到“已暂存”，随后 rebase 进度继续变化。若 Git 提示提交说明编辑器，保存并关闭即可；如果下一提交再次冲突，不要重复使用上一次的选择，重新阅读当前补丁。

不确定时怎样检查和回退

保留两边并不等于两边文本都能直接拼接。重点检查重复配置、函数是否出现两次、导入是否重复，以及当前提交的业务意图是否仍然完整。可以先查看差异，再决定是否继续：

# 查看工作区与暂存区差异，检查人工合并是否留下重复内容
git diff

# 查看已暂存结果，确认提交前的最终文件
git diff --cached

# 如果无法判断，退出本次变基并回到开始前的分支状态
git rebase --abort

git rebase --abort 适合“这次合并方向判断错了”或“需要先和团队确认”的情况；它不是删除远端分支，而是结束当前 rebase 并恢复开始前的状态。确认内容和测试策略后，再重新开始变基。

常见问题

rebase 里为什么 ours 和 theirs 看起来反了？

因为 rebase 正在把当前分支提交重放到上游之上，Git 官方文档说明冲突时两侧的语义可能与普通 merge 相反。先看当前补丁和提交来源，再决定保留哪一边。

能不能直接使用 git checkout --theirs？

可以处理整文件，但不适合“保留两边片段”的目标，而且 rebase 时语义容易误判。优先按冲突块编辑；需要整文件选择时，使用当前 Git 文档对应的 git restore 写法并核对上下文。

冲突解决后还要做什么？

必须删除标记、保存文件、执行 git add，再执行 git rebase --continue。最后检查状态和提交差异，确认没有误删业务逻辑。