git默认myers算法易产生假冲突，patience算法通过匹配唯一行减少误判，适合严重分叉分支合并；配置git config [--global] merge.strategy-option patience即可启用，需配合merge.renormalize true等提升效果。
Git 默认的 diff 算法（myers）在面对大量变更、结构相似但语义无关的代码块（如多个函数的大括号、重复的 import 语句、长段注释或空行）时，容易误判“匹配行”，从而把本不该冲突的地方标为冲突，或掩盖真正重叠的业务逻辑修改。而 patience 算法通过只匹配**唯一出现的行**来构建差异，能显著减少这类“假冲突”，尤其适合合并分支间已发生严重分叉（如数月未同步的 feature 分支）的场景。
配置全局或仓库级 patience 合并策略
只需一条命令即可让 Git 在所有 git merge（含 git pull）中默认启用 patience 差异算法：
- 对当前仓库生效：
git config merge.renormalize true && git config merge.ff false && git config merge.conflictstyle diff3（可选增强可读性）git config merge.strategy-option patience - 对当前用户所有仓库生效（推荐长期使用）：
git config --global merge.strategy-option patience
注意：该配置仅影响 merge-recursive 策略（Git 默认合并策略），无需额外指定 -s recursive。
验证配置是否生效
执行以下命令查看当前 merge 相关配置：
-
git config --get merge.strategy-option→ 应输出patience -
git config --get merge.renormalize→ 建议设为true，确保重命名/格式化变更也被正确识别 - 合并前可手动测试效果：
git merge-tree $(git merge-base HEAD feature-branch) HEAD feature-branch | grep -A5 -B5 "conflict"（观察冲突标记是否更聚焦于真实逻辑重叠）
配合其他策略提升合并稳定性
单独用 patience 不足以解决所有问题，建议组合使用：
-
预检再合并：运行
git merge --no-commit --no-ff feature-branch，先检查冲突位置和数量，确认无误再git commit -
避免空行/注释扰动：在团队规范中约定，不单独提交纯格式化改动（如调整缩进、增删空行），或使用
git add -p精确暂存 - 大变更拆分提交：将巨型 PR 拆为若干语义清晰的小提交（如 “refactor: extract validation logic” + “feat: add email validation UI”），patience 对小粒度变更识别更准
何时不用 patience
它不是万能解药：
- 对极短文件（如单行 shell 脚本）、或高度重复内容（如生成的 JSON/CSV）效果有限
- 会略微增加合并前的计算时间（通常可忽略）
- 无法规避真正的逻辑冲突——比如两人同时修改同一函数的同一判断条件，这必须人工决策
