git 仅在同时满足四个条件时自动启用 octopus 合并：目标为三个及以上分支、任意两分支间无共同祖先冲突、无内容冲突、未指定其他策略；否则会静默回退至 recursive。
git merge 默认用 recursive 策略，只支持两个分支合并；要一次把 3 个及以上无冲突的特性分支合进主干，必须显式触发 octopus 策略——它不解决冲突，但能生成一个含多个父提交的干净合并节点。
什么时候 Git 会自动用 Octopus Merge？
Git 只在满足全部以下条件时才自动选择 octopus：
- 当前分支要合并的目标是3 个或更多分支名/提交（如 git merge feat/a feat/b feat/c）
- 所有被合并分支与当前分支没有两两之间的共同祖先冲突（即任意两个分支之间不能存在未解决的 divergent 修改）
- 所有分支间不存在内容冲突（文件同一行被不同分支修改）
- 没有指定其他策略（如 -s recursive）
手动触发 Octopus Merge 的正确写法
别依赖自动判断，尤其在 CI 或脚本中——显式指定更可靠：
- ✅ 正确：git merge -s octopus feat/login feat/payment feat/profile
- ❌ 错误：git merge -s octopus feat/login（只有一个分支，Git 会 fallback 到 recursive）
- ❌ 错误：git merge feat/login feat/payment --no-commit（--no-commit 会禁用 octopus，强制退回到 recursive）
- ⚠️ 注意：octopus 不接受 --squash、--no-ff 等修饰选项，加了会被忽略或报错
Octopus Merge 失败的典型错误信息
遇到这些提示，说明不满足 octopus 前提，Git 已 fallback：
- error: commit ... is a merge but has no -m option：你试图对已有合并提交再做 octopus，但没加 -m（其实根本不需要，这是误判）
- fatal: Not possible to fast-forward, aborting.：分支间存在线性不可解关系，Git 放弃 octopus，但也没走 recursive，直接卡住
- 更常见的是静默 fallback 到 recursive，然后报冲突——此时 git status 显示 “both modified”，说明它根本没走 octopus 路径
为什么不能用 Octopus Merge 解决冲突？
octopus 的设计目标不是交互式处理分歧，而是原子化整合已确认兼容的多路变更：
- 它不启动三方比较（no 3-way merge），也不读取 index 中的冲突标记
- 一旦检测到任一文件在两个以上分支中有修改，立即终止并报错 refusing to merge unrelated histories 或类似提示
- 所以它适合发布前的“功能集合”操作（如集成测试通过的多个独立模块），不适合日常开发中边改边合
- 若真需要合并带冲突的多分支，得先两两用 recursive 合并消解，再对结果用 octopus
真正用好 octopus，关键不是命令怎么敲，而是提前验证分支间是否真正正交——看提交图谱比看文件列表更准，git log --graph --oneline feat/a feat/b feat/c 里若出现交叉线，基本就别试了。
