Git merge-ort 与 rebase-merges 处理冲突有什么区别

如果你只是把一条功能分支并入当前分支，ort 是 Git 用来完成两头三方合并的策略；如果你想在变基时把本地已有的合并提交也重建出来，才使用 git rebase --rebase-merges。它们不是两个同层级的“冲突算法”：前者回答“这次合并怎么合并”，后者回答“变基时是否保留并重建合并拓扑”。

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

处理冲突前先看历史目标：要保留一次真实的合并提交，用普通 merge；要把尚未公开的本地分支整体搬到新基线并保留分支结构，用 rebase-merges。冲突解决后，两条路径的继续命令和最终提交形状也不同。

先判断：你是在合并，还是在重建历史

“冲突”这个词容易把两件事混在一起。普通合并把当前分支和另一个分支的两端交给合并后端，ort 会寻找共同祖先并完成三方合并；它可以处理重命名，也会把不冲突的两侧改动带入结果。它并不负责改写已经存在的提交序列。

--rebase-merges 属于 rebase 模式。它会把提交按 todo 列表重放，并用 label、reset、merge 等动作重建本地合并提交。重建 merge 命令时，Git 默认使用 ort，所以“rebase-merges 对比 ort”更准确的理解是“变基工作流里调用了 ort 来处理其中的合并点”。

在原创界面示意中，左侧的分支图只帮助定位入口，不代表某个真实 Git 客户端。实际菜单名称会因客户端不同而变化，命令行选项才是本文的稳定依据。

第1步：先保存安全分支，再确认当前拓扑

进入常见 Git 图形客户端的 Branches → 当前分支 → Create safety branch，创建一个只用于回退的本地分支。然后打开 History → Graph，确认当前分支是否已经包含本地 merge commit。若工作区还有未提交改动，先保存或暂存，不要在不清楚状态时直接启动变基。

# 为即将尝试的历史操作建立可回退的指针
git branch backup-before-history-change

# 用提交图确认当前分支、共同祖先和已有合并点
git log --graph --oneline --decorate --all -20

完成标志是分支图里能看见备份分支，并且你能指出“当前分支”“目标分支”和已有合并提交的位置。若只是把 topic 合进 main，通常不需要为了保留拓扑而启动 rebase。

第2步：按历史目标选择 merge-ort 或 rebase-merges

在图形客户端中，普通整合通常位于 Branches → Merge into current branch；需要保留本地合并提交的变基通常位于 Branches → Rebase current branch → Preserve merges。不同客户端可能把第二项写成“Rebase with merges”，如果看不到该选项，就用命令行明确表达意图。

# 普通整合：把 topic 合到当前分支，显式指定 ort 合并策略
git merge -s ort topic

# 本地历史尚未公开时：把当前分支搬到新基线并重建合并提交
git rebase --rebase-merges --strategy=ort origin/main

选择依据很简单：需要一个“这两条历史在这里汇合”的记录，就用普通 merge；需要把一组本地分支结构搬到新基线，并接受提交 ID 被重写，就用 rebase-merges。公开分支不要随意变基，因为它会让协作者看到一套新的提交身份。

第3步：根据当前操作继续或终止

普通 merge 的冲突通常围绕“当前分支、目标分支、共同祖先”展开；rebase-merges 的冲突可能出现在某个被重放的普通提交，也可能出现在重新执行 merge 动作时。因此不要只看冲突文件名，要先看状态提示当前正在进行哪一种操作。

# 查看 Git 当前把冲突归在哪一种操作上下文
git status

# 手工编辑冲突文件后，把已经决定的结果加入暂存区
git add path/to/conflicted-file

# 普通 merge 继续创建合并提交
git merge --continue

# rebase 或 rebase-merges 继续重放下一个提交
git rebase --continue

完成标志不是“冲突标记消失”这么简单，而是状态面板不再列出未解决文件，并且继续按钮对应当前操作。若发现选择错了，图形客户端的 Abort current operation 对应命令如下：

# 放弃一次普通合并，回到合并开始前
git merge --abort

# 放弃一次普通变基，回到变基开始前
git rebase --abort

第4步：检查历史形状，再决定是否发布

继续完成后，打开 History → Graph → Compare with backup。普通 merge 预期能看到一个新的 merge commit；rebase-merges 预期保留本地分支关系，但被重放的提交会拥有新的提交 ID。这个差异就是两者最重要的结果边界。

常见问题

ort 是不是 rebase-merges 的替代方案？不是。ort 是合并策略，rebase-merges 是变基模式；rebase-merges 重建 merge 命令时默认会使用 ort。

冲突解决后为什么提交 ID 变了？因为 rebase 会把提交重新应用到新基线，父提交或内容发生变化后，提交身份自然会重新计算。

什么时候优先用普通 merge？当分支已经共享、需要保留整合节点，或团队不希望改写公开历史时，普通 merge 更稳妥。

官方文档在哪里？合并策略说明：https://git-scm.com/docs/merge-strategies；变基说明：https://git-scm.com/docs/git-rebase.html。