合并策略是什么
合并策略决定 Git 用什么算法把两条历史汇到一起。默认策略会处理三方合并与重命名检测，绝大多数仓库根本不需要显式指定。只有在明确知道结果应该是什么样子时才用得上：例如按目录合并子项目，或者整体以本分支为准。
几种内置策略的用途
ort 是当前默认策略，三方合并与重命名检测较完整；resolve 是较早的算法，现在很少使用；octopus 用于一次合并多个分支；ours 会忽略对方全部内容只留下合并记录；subtree 按子目录对齐进行合并，用于没有使用子模块元数据的旧式布局。
基本信息
| 适用平台 | Linux / macOS / Windows（Git 2.x） |
|---|---|
| 语法 | git merge -s <策略> <分支> |
| 默认策略 | ort，Git 2.34 起成为默认 |
| 常见策略 | ort、resolve、octopus、ours、subtree |
| 策略选项 | -X 只影响冲突处理细节，与 -s 不同 |
| 使用频率 | 日常合并几乎不需要显式指定 |
典型使用场景
- 批量汇入：用 octopus 一次合并多条互不冲突的分支
- 以本分支为准：用 ours 合入一条内容不需要的分支，只保留合并关系
- 子项目目录：用 subtree 处理未使用子模块元数据的旧式布局
- 兼容历史：维护老仓库时遇到 resolve 的历史用法
- 谨慎排查：非常规合并出现异常时确认实际使用了哪种策略
常用示例
常用示例
git merge feature/login # 默认策略，常规合并
git merge -s octopus a b c # 一次合并多个分支
git merge -s ours legacy/old # 忽略对方内容，只记录合并
git merge -s subtree vendor/lib # 按子目录对齐合并
git merge -X ours feature/login # 仅冲突块以我方为准常见策略对照
| 策略 | 行为 | 使用场景 |
|---|---|---|
| ort | 三方合并，重命名检测较完整 | 默认，常规合并 |
| resolve | 较旧算法，仅文件级三方合并 | 极少使用，历史兼容 |
| octopus | 一次合并多个分支 | 多分支批量汇入且无冲突 |
| ours | 忽略对方全部内容，仅记录合并 | 明确以本分支为准 |
| subtree | 按子目录对齐合并 | 旧式子项目布局 |
大多数仓库不需要修改合并策略。跨项目合并时优先考虑子树或子模块方案，而不是长期依赖 -s subtree。
-s ours 会彻底忽略对方改动。如果对方分支里其实有需要保留的提交，这一步会静默丢掉它们，事后很难发现。