git无法自动解决真正冲突，所谓“自动”实为强制单边覆盖（ours/theirs），仅适用于ci产物、锁文件等特定场景；需人工判断逻辑意图，否则易丢关键功能。
Git 无法真正“自动合并冲突文件”，所谓“自动”只是指跳过人工干预、按预设规则单边覆盖 —— 这本质是放弃协商，不是解决冲突。 真正的冲突必须由人判断逻辑意图；所有标榜“自动解决”的配置，实际都是用 ours、theirs 或自定义脚本强制选一边，风险极高，仅适用于特定场景（如生成文件、配置模板）。
什么时候能用 git merge --strategy=ours 安全跳过冲突
这个策略不尝试合并，直接丢弃对方分支的所有变更，只保留当前分支内容。它只适合明确“我方版本绝对权威”的情况：
- 合并 CI 构建产物目录（如
dist/、build/），这些文件本就不该进 Git，但误提交后需快速清理 - 回滚误合入的实验分支：已确认该分支所有改动都应废弃，且无其他依赖它的后续提交
- 子模块或子仓库（如
git-subrepo）中，本地覆盖远端元数据（需配合--no-commit先检查）
⚠️ 注意：git merge -s ours 不会报错，也不会提示冲突，但它会静默丢弃对方全部修改 —— 如果你没看清 git log --oneline --left-right featureB...main 的差异范围，极易删掉关键功能。
.gitattributes 中配置 merge=ours 的真实作用
这不是全局开关，而是对**特定文件类型**启用单边覆盖策略，避免每次手动加参数。典型用法：
-
*.md merge=ours：文档文件常被多人编辑同一段，但主分支的 README 必须由负责人终审，禁止他人直接覆盖 -
package-lock.json merge=ours：npm 锁文件应以主分支为准，避免因本地 node_modules 差异引入不一致依赖 -
config/*.yml merge=theirs：环境配置由运维统一维护，开发分支只读不改，合并时强制采用远端版本
配置后需确保对应驱动已注册：git config --global merge.ours.driver true（内置策略无需额外注册），否则会 fallback 到默认 recursive 并照常报冲突。
为什么 git merge -X ignore-space-change 不算“自动解决”
这个选项属于“合并策略扩展参数”（-X），它让 recursive 策略在比对时忽略空格和换行差异，从而减少触发冲突的概率 —— 但它不会处理真正的语义冲突。例如：
if (x == 1) { // HEAD 版本
doA();
}
vs
if (x === 1) { // feature 分支版本
doB();
}
即使开启 -X ignore-space-change，这两行仍会被识别为不同逻辑而产生冲突，因为空格无关，但 == 和 === 是语义级差异。这类参数只能降低冲突频率，不能替代人工判断。
自定义合并脚本真正起效的关键条件
写一个 custom_merge.py 并配进 .gitattributes 后，它只会在 Git 判定“此处有冲突”时才被调用。这意味着：
- 脚本必须能解析标准冲突标记（
/ <code>=======/>>>>>> feature），不能假设输入是干净 diff - 输出必须是合法文件内容（无冲突标记、语法正确），否则
git add会失败 - 脚本退出码决定成败：成功返回 0，失败返回非 0（Git 会继续报冲突）
- 它只对
.gitattributes指定的路径生效，对未声明的文件类型无效
最易被忽略的一点：Git 在调用脚本前，会把冲突内容通过 stdin 传入，而不是传文件路径 —— 所有基于路径做逻辑判断的脚本（比如“如果是 config.json 就走 A 规则”）必须先从 stdin 解析出原始文件名，否则规则失效。
