--ours和--theirs不是万能开关：merge用-xours/-xtheirs（策略选项），checkout/reset用--ours/--theirs（文件恢复），语义不同、混用报错；前者干预冲突裁决，后者覆盖已标记冲突文件。
直接说结论：--ours 和 --theirs 不是“跳过冲突”的万能开关，它们只在特定上下文中生效——merge 时用 -Xours 或 -Xtheirs，checkout/reset 时用 --ours 或 --theirs，两者语义完全不同，混用会出错。
merge 命令里的 -Xours 和 -Xtheirs 是什么
这是 git merge 的策略选项（-X 表示 “eXtended”），只对 recursive 或 ort 这类三路合并策略起作用。它不改变合并逻辑，只干预冲突发生时的自动裁决方式。
-
git merge -Xours feature：当feature合入当前分支时，所有冲突块都保留当前分支（our side）的版本，但非冲突部分仍会合并对方改动 -
git merge -Xtheirs feature：同理，冲突块全取feature分支的版本 - 注意：它不影响二进制文件以外的文件类型判断；对二进制文件，
-Xours直接整份用当前分支内容，-Xtheirs整份用feature分支内容 - 它不等价于
ours合并策略（-s ours），后者会完全忽略对方所有变更，连非冲突部分都不合并
checkout/reset 里的 --ours 和 --theirs 容易踩坑
这是针对已存在冲突的工作区文件的操作，不是 merge 参数。必须配合 git checkout 或 git restore 使用，且仅作用于指定路径。
-
git checkout --ours -- hello.py：把hello.py冲突中 ours 部分（即当前分支 HEAD 的版本）写入工作区，覆盖冲突标记 -
git checkout --theirs -- hello.py：同理，写入feature分支的版本 - ⚠️ 错误写法：
git merge -Xours --ours——--ours在merge命令里是非法参数，Git 会报错unknown option: --ours - ⚠️ 忘记
--分隔符：比如git checkout --ours hello.py缺少--，Git 可能误判hello.py为分支名，导致切换分支而非恢复文件
什么时候该用 -Xours/-Xtheirs，而不是手动解决
适用场景非常有限，核心原则是：**你明确知道哪边的修改在语义上应该无条件优先，且冲突范围可控**。
- 配置文件合并：比如
config.yml在 dev 分支改了数据库地址，在 main 分支只加了日志级别，你确定上线环境必须用 main 的地址 →git merge -Xours dev - 自动化脚本更新：CI/CD 脚本被工具自动生成并提交到 feature 分支，而你本地有少量手工注释 →
git merge -Xtheirs ci-scripts保工具生成内容 - 不要用于业务逻辑文件：哪怕只是“看起来”冲突简单，
-X会跳过人工审查，可能掩盖逻辑覆盖或字段遗漏 - 不能替代测试：即使用了
-Xtheirs，也得跑一遍单元测试，确认对方逻辑没破坏你的调用链
合并后发现 -X 选错了怎么办
只要还没 push，就还有回旋余地。关键点在于：Git 不会丢弃任何一方的原始提交，只是 merge 提交的 tree 对象用了你指定的裁决结果。
- 撤销 merge 提交：
git reset --hard HEAD~1（仅限本地未推送） - 重做 merge 并换策略：
git merge -Xours feature改成git merge -Xtheirs feature，或干脆去掉-X手动解决 - 如果已 push，只能新建 revert 提交：
git revert -m 1 HEAD（-m 1指定主干为第一父提交），再重新 merge - 最隐蔽的坑：
-Xours合并后，git log --merge看不到冲突文件的 diff，因为 Git 认为“已自动解决”，但实际可能漏掉了对方的关键 fix
真正难的不是记住参数拼写，而是判断“这个冲突是否真的适合交给 -X 自动裁决”。大多数时候，打开编辑器看一眼冲突上下文，比查文档敲命令花的时间更少，也更安全。
