ours合并策略以当前分支head为基准，仅保留其内容并创建合并提交，用于标记已评估但拒绝引入对方变更的场景。
什么是 ours 合并策略，它真能“强制保留当前分支”？
ours 是 Git 内置的合并策略之一，但它不等于“忽略对方所有变更”。它的实际行为是：在发生冲突时，**自动选择当前分支（HEAD）的版本，丢弃来自 theirs 分支的修改**；但对无冲突的文件，仍会正常合并——也就是说，ours 只影响冲突区域的决策，不是全局覆盖。
常见误解是以为执行 git merge -s ours feature 就能让当前分支“原封不动”，其实它只是让这次合并提交成为一个“空变更”的占位符（即合并后工作区与 HEAD 完全一致，但历史里记录了 feature 已被合并过）。
什么时候该用 git merge -s ours？
典型适用场景是：你明确不想引入对方分支的任何代码逻辑，但需要在 Git 历史中留下“已评估/已拒绝”的标记。比如：
- 临时实验分支被否决，但团队要求保留合并记录
- 发布分支（如
release/v2.1）需合入开发分支以同步提交点，但不允许任何功能变更落地 - CI 流水线中做“安全合并”兜底（配合
--no-ff和人工 review）
注意：-s ours 不能替代 git reset 或 git revert。它不撤销已有提交，只控制本次合并的快照内容。
执行 git merge -s ours 的正确姿势
直接运行命令即可，无需额外配置。但必须注意以下几点：
- 确保当前在目标分支上（例如你在
main上想保留全部内容，就先git checkout main） - 命令格式为：
git merge -s ours <branch-name></branch-name>，例如git merge -s ours dev - Git 不会提示冲突，也不会打开编辑器；它直接创建一个合并提交，其 tree 对象与
HEAD完全相同 - 如果后续还需把
dev的某些特定提交挑出来用，得靠git cherry-pick，因为-s ours合并后那些提交在main的历史中不可达
示例输出：
Auto-merging README.md CONFLICT (content): Merge conflict in README.md Auto-merging src/index.js Automatic merge failed; fix conflicts and then commit the result.
等等——这其实是误用了。上面错误说明你没加 -s ours，或者用了其他策略。真正执行 -s ours 时，Git 根本不会触发冲突处理流程，也不会修改工作区文件。
容易被忽略的关键限制
-s ours 策略有硬性边界：
- 它只对两路合并（
git merge A）有效；三方合并（如git merge --no-ff多个分支）不支持该策略 - 无法用于
git pull（因为pull默认走recursive策略），必须拆成git fetch && git merge -s ours - 它生成的合并提交没有实际差异，
git diff HEAD^..HEAD返回空；CI 工具若依赖 diff 判断变更，可能跳过构建 - 如果对方分支含子模块更新、权限变更或符号链接，
-s ours不保证这些元信息被忽略——它们可能仍被纳入索引，需手动检查git status
最常踩的坑是：把它当成“反向 rebase”来用。实际上，一旦用了 -s ours，那个分支在当前分支上的可追溯性就断了——除非你记得保存原始提交哈希，否则很难找回当初被跳过的改动。
