Git的merge.strategy配置和--strategy参数不能减少逻辑冲突，仅辅助处理已发生的冲突；真正降低冲突靠协作规范。ours和theirs策略直接跳过冲突检测并单向覆盖，patience和recursive（含-X选项）可减少假冲突但不解决逻辑重叠。
Git 的 merge.strategy 配置和 --strategy 参数不是用来“减少逻辑冲突”的魔法开关，而是帮你更可控地处理已发生的冲突，或在特定场景下绕过某些冲突判断。真正减少逻辑冲突靠的是协作规范和提交习惯，策略只是辅助手段。
哪些策略能实际影响冲突行为
Git 内置的合并策略中，真正对冲突判定有直接影响的主要是以下两个：
- ours：完全忽略待合并分支的修改，保留当前分支（HEAD）的所有内容。适合快速丢弃某个功能分支的全部变更，比如临时测试分支误推到集成分支后紧急回撤。
- theirs：完全采用待合并分支的修改，丢弃当前分支对应位置的改动。适合你确认“对方改得对、我这版要彻底覆盖”，例如合并上游安全补丁时放弃本地旧配置。
注意：ours 和 theirs 不是“自动解决冲突”，而是跳过冲突检测直接覆盖——如果两个分支都改了同一行，Git 不再报错，而是无条件按指定方保留。这有风险，必须明确知道后果。
Git Repo Reader
下载
辅助阅读和快速理解 GitHub/Git 项目结构与核心价值的结构化方法论。 当用户请求"分析这个 GitHub 项目"、"帮我读一下这个 repo"、"了解这个项目是做什么的"、 "怎么用这个项目"、"怎么跑这个项目"、"这个项目用了哪些技术"，或任何涉及 GitHub/Git 仓库阅读、理解、技术评估、快速上...
如何配置和使用这些策略
策略可在命令行临时指定，也可设为分支级默认值：
- 单次合并用
ours：git merge --strategy=ours feature/login - 想让某个分支（如
release/v2.1）每次合并都倾向保留自身内容，可配置：git config branch.release/v2.1.mergeOptions "--strategy=ours" - 全局默认策略不推荐，但若团队约定所有 hotfix 合并都以修复分支为准，可设：
git config --global merge.defaultToUpstream true（配合--strategy=theirs使用需谨慎）
其他策略的适用边界
有些策略看似能“智能避冲突”，实则只改变 diff 算法，不改变冲突本质：
- patience：用更严格的行匹配算法，适合长文件（如 SQL 脚本、XML），减少因空行或注释错位引发的假冲突，但对业务逻辑重叠无效。
-
recursive（默认）：支持单个共同祖先的常规合并；加
-X选项可微调，例如：git merge -Xignore-space-change feature/docs忽略空格差异，避免格式调整触发冲突。 -
resolve：老式简单策略，基本被
ort（现代默认）取代，无需主动选用。
比策略更重要的预防动作
策略再灵活，也治不了根本问题。真正降低逻辑冲突发生率的操作更实在：
- 每天早/晚执行
git pull --rebase origin/main，让本地变更始终基于最新主线，避免“越积越多”的累积差异。 - 功能分支命名带上下文，如
feat/user-profile-api-v2，而不是feature1，方便队友预判修改范围。 - 对配置文件、路由表、枚举定义等易冲突文件，约定“谁新增谁维护”，避免多人同时增删同一 section。
- 启用
git config --global merge.conflictstyle diff3，冲突标记中多出祖先版本，一眼看出“原来是什么、A改成啥、B改成啥”，决策更快更准。
