git merge -s ours 是强制保留当前分支、静默丢弃对方所有改动的单边覆盖策略，仅适用于ci产物、锁文件或已确认废弃的实验分支回滚等极窄场景，否则易导致关键功能丢失。
Git 不能真正“自动合并冲突”，所谓自动，只是用 ours 或 theirs 策略跳过人工干预、单边覆盖 —— 这不是解决，是丢弃。真冲突必须人判逻辑，否则上线就炸。
git merge -s ours 是什么，什么时候敢用
它不比较、不协商，直接扔掉对方分支所有改动，只留当前分支内容。本质是“强制保留 HEAD”。
-
git merge -s ours feature后，feature分支所有新增/修改的代码全消失，连文件删了都不会还原 - 适用场景极窄：CI 构建产物（
dist/）、锁文件（package-lock.json）、已确认废弃的实验分支回滚 - ⚠️ 危险点：命令不报错、不提示冲突、不生成 diff —— 你 run 完以为合并成功，其实关键功能已被静默删除
- 验证方式：合并前先跑
git log --oneline --left-right feature...main，确认那侧（feature）确实全是该丢的内容
.gitattributes 里配置 merge=ours 的真实作用
这是对**特定文件类型**启用单边策略，不是全局开关。它让 Git 在遇到这些文件冲突时，自动走 ours 逻辑，省得每次手动加 -s ours。
- 典型写法：
*.md merge=ours（文档由主分支终审）、package-lock.json merge=ours（锁文件以 main 为准） - 必须确保驱动已注册：
git config --global merge.ours.driver true（内置策略通常不用配，但漏配会导致 fallback 到默认recursive并照常报冲突） - 注意：只对新冲突生效；已存在的冲突标记不会被自动清理，仍需
git add提交 - 不适用于源码文件 ——
merge=ours用在src/index.ts上，等于授权 Git 删除别人写的业务逻辑
rerere 能“自动解决”冲突吗
rerere 不解决冲突，它只记录你**上次怎么手动解决的**，下次遇到一模一样的冲突块（相同 preimage + same hunk），才帮你填回去。它不是 AI，是记忆胶带。
- 启用命令：
git config --global rerere.enabled true - 首次冲突解决后，Git 会输出
Recorded preimage for 'xxx'；第二次遇到相同冲突，会显示Resolved 'xxx' using previous resolution - 它不管语义 —— 如果你上次手误删了 if 判断，rerere 下次照样帮你删
- 适合长期维护分支、频繁 rebase、或多个主题分支轮流合入测试分支的场景；不适合一次性合并或逻辑常变的模块
- 查看记录：
git rerere status；清除某条：rm .git/rr-cache/xxx
为什么 git merge -X ignore-space-change 不算自动解决
这个选项只是让 recursive 策略在比对时忽略空格、换行、tab 差异，从而减少“假冲突”。但它对语义冲突完全无感。
- 比如：
if (x == 1)vsif (x === 1)，即使开了-X ignore-space-change，Git 仍会报冲突 —— 因为==和===是不同操作符 - 它不改变三路合并的底层逻辑：只要 BASE、HEAD、THEIRS 三方中任意两方在相同行有不同内容，就触发冲突
- 适合清理格式化差异，但不能替代人工判断；滥用反而掩盖真实逻辑分歧
- 临时启用：
git merge -X ignore-space-change feature；全局配置不推荐，容易让团队误以为“格式不重要”
真正的难点从来不在怎么配命令，而在判断哪一行该留、哪一段逻辑不可丢、谁改的才是最终意图 —— 这些没法交给 Git，得靠人盯日志、读上下文、问作者。配置只是把重复劳动减到最少，不是把责任甩出去。
