应根据文件类型和协作场景选择 ours/theirs：ours 适用于保留当前分支配置（如 ci 脚本），theirs 适用于集成上游文档更新；误用会导致关键代码丢失，须配合 --no-commit 审核变更。
直接用 --strategy 和 -X 选项就能跳过手动编辑冲突文件，但必须匹配场景，否则会丢代码或掩盖真实问题。
什么时候该用 ours 或 theirs 策略
这两个不是“选一个分支完事”的捷径，而是有明确适用边界的覆盖策略：
-
ours适合合并第三方配置分支（如 CI 脚本模板）时，你只想要保留当前分支的定制内容，完全忽略对方对同名文件的改动 -
theirs常用于集成上游库更新：比如你 fork 了一个开源项目，上游改了README.md，而你本地没动它，这时git merge upstream/main -X theirs可安全取上游版本 - 误用风险极高：若在业务逻辑文件上滥用
-X ours，可能把对方修复的关键 bug 行直接抹掉，且 Git 不报错、不警告 - 注意区分
-X ours（解决冲突块）和--strategy=ours（整个合并放弃对方所有变更）——后者连非冲突部分也丢弃
ort 策略下启用重命名检测能减少 30%+ 冲突
Git 2.39+ 默认使用 ort，但它默认关闭重命名检测。很多“文件被删又新建”的冲突，其实是同一文件被重命名后修改导致的：
- 开启方式：
git merge feature-branch -X find-renames=40%，数值越低越敏感，40% 是经验平衡点 - 效果明显场景：重构时批量重命名类/组件文件，同时另一分支在原名文件里加了日志行
- Windows 用户额外注意：
git config core.ignorecase true必须提前设置，否则find-renames在大小写混用路径下失效 - 禁用 renames 检测的副作用：Git 会把重命名+修改识别为“删除旧文件 + 新增文件”，触发大量人工介入
用 .gitattributes 对特定文件类型预设合并逻辑
比每次命令加参数更稳定，尤其适合团队统一处理配置文件、二进制资源等易冲突类型：
- 在项目根目录建
.gitattributes，写入：*.json merge=ours *.png merge=union *.md merge=theirs
-
merge=ours表示所有.json文件冲突时自动取当前分支版本；merge=union对图片无效，但对文本类资源（如 SQL 迁移脚本）可合并多行 - 必须提前全局注册驱动：
git config --global merge.ours.driver true（true是 shell 命令，表示“无条件接受 ours”） - 常见坑：如果某
.json文件在双方都新增了不同 key，merge=ours会直接丢弃对方新增字段，而非合并对象
--no-commit + -X 组合是安全调试关键
任何带 -X 的策略都建议配合 --no-commit 使用，否则冲突被“静默解决”后提交，很难回溯问题源头：
- 执行：
git merge dev -X find-renames=50% --no-commit - 然后立刻检查：
git status看哪些文件被标记为 modified（说明策略生效），哪些仍是 unmerged（说明策略未覆盖到） - 再运行：
git diff --cached查看实际被自动采纳的变更，确认是否符合预期 - Windows 上尤其要小心：某些 IDE（如 VS Code）在
--no-commit状态下仍会自动保存文件，导致后续git add时混入未审核的修改
真正难的不是选哪个策略，而是判断“这个冲突到底该不该自动解决”。比如两个分支都改了同一个函数的返回值类型，-X theirs 可能让编译直接失败——策略本身没错，错在没先看清语义冲突。
