--ours和--theirs是冲突解决选项而非合并策略，-s ours/-s theirs才是独立策略；merge与rebase中二者指向相反，混用会丢代码：-xours仅对冲突文件选当前分支版本，-s ours则彻底忽略被合并分支所有更改。
Git 的 --ours 和 --theirs 不是合并策略（merge strategy），而是冲突解决选项（strategy option）；真正叫 ours 和 theirs 的才是独立的合并策略，二者语义和使用方式完全不同，混用会直接丢代码。
别把 -Xours 当成 -s ours 用
这是最常踩的坑：看到名字相似就以为功能一样。实际完全不是一回事。
-
git merge -Xours branch：在recursive策略下，仅对发生冲突的文件，自动选择当前分支（--ours）版本，其余无冲突部分照常合并 -
git merge -s ours branch：完全忽略branch上所有改动，新提交只记录“已合并”，内容 100% 来自当前分支 ——branch的任何变更都彻底消失 -
git merge -s theirs branch：Git 原生不支持该策略，需靠git merge -s ours反向操作（如先 checkout 到目标分支再 merge 当前分支）模拟，或用git read-tree手动构造
--ours 和 --theirs 在冲突时怎么选才不翻车
它们只在冲突标记存在时生效，且含义取决于你正在执行的操作类型 —— merge 和 rebase 中角色反转。
- 执行
git merge feature（当前在main）：
•git checkout --ours file.txt→ 保留main的版本
•git checkout --theirs file.txt→ 保留feature的版本 - 执行
git rebase main（当前在feature）：
•git checkout --ours file.txt→ 保留main的版本（即“参考分支”）
•git checkout --theirs file.txt→ 保留feature的版本（即“当前分支”） - 二进制文件（如
.docx、.png）无法自动 diff，冲突时必须用--ours/--theirs显式指定，否则git add会失败
什么时候该用 -s ours 而不是 -Xours
场景非常明确：你只想留个合并记录，但坚决不要对方分支的任何代码变更。
- 清理废弃分支：比如
legacy-ui分支已停用，但需在main上留下“已评估/已弃用”痕迹，用git merge -s ours legacy-ui - 集成 CI/CD 配置分支：某些配置仓库按环境分叉，但生产环境只允许从主干同步，其他分支的修改一律不采纳
- 注意：
-s ours合并后，git log --merge看不到被忽略分支的提交历史，它真的被跳过了，不是隐藏
-Xtheirs 在持续集成中容易被低估的风险
看似“全盘接受对方代码”很省事，但实际会掩盖真实问题。
- 如果对方分支有未测试的实验性改动，
-Xtheirs会让这些改动无声无息进入当前分支 - CI 流水线若没做
git diff HEAD^ HEAD校验，可能漏掉意外引入的敏感配置（如本地调试开关、硬编码密钥） - 多人协作时，
-Xtheirs合并后若没人git show确认内容，下次 rebase 就可能把不该保留的改动带进主线
真正麻烦的从来不是命令记不住，而是没想清楚“这个文件我到底想保留谁的版本”——--ours/--theirs 是快刀，但刀锋朝哪，得先看清血线在哪。
