git 合并 xml 冲突主因是格式/顺序差异被误判为语义变更，需通过预格式化、属性标准化、拆分文件、schema 验证及 blame 过滤等手段从源头治理。
Git 合并时 XML 文件显示大量冲突，但实际只是格式或顺序变化
Git 默认把 XML 当纯文本比对，<item></item> 标签换行、缩进变动、属性顺序调整（比如 id="1" name="a" 和 name="a" id="1"）都会触发整行冲突，哪怕语义完全一致。
- 用
git diff --no-index手动对比两个 XML 文件前，先用工具标准化：比如用xmllint --format --nsclean统一缩进和命名空间声明 - 在
.gitattributes中为 XML 文件启用 text + whitespace 忽略：*.xml text eol=lf whitespace=indent-in-code，但注意这仅影响空格/制表符，不解决属性顺序问题 - 真正有效的做法是合并前预处理：提交前运行脚本自动格式化（如
xmllint --format --output %f %f），确保团队统一格式，从源头减少无意义冲突
多个开发者同时修改同一段 XML 结构（如 下新增 ）
这类冲突本质是「逻辑并发」——不是谁改了哪一行，而是两人各自插入了新节点，Git 无法判断是否可安全叠加。
- 避免在长列表末尾盲目追加；改用带唯一标识的结构，例如每个
<plugin></plugin>必须有id属性，并在文档头部维护<plugin-registry></plugin-registry>做索引 - 合并时别直接选 ours/theirs；用
git mergetool配合支持 XML 的工具（如xxdiff或 VS Code 的 XML Tools 插件），能按元素层级高亮差异 - 如果项目允许，把大 XML 拆成小文件（如
plugins/redis.xml、plugins/kafka.xml），用<include></include>聚合，Git 冲突粒度就变成文件级而非行级
XML Schema（XSD）变更后，旧版配置文件被新解析器拒绝
版本控制只管内容，不管语义兼容性。XSD 升级后，旧 XML 可能仍能通过 Git 合并，但运行时报 SAXParseException: cvc-complex-type.2.4.a。
- 每次 XSD 修改，必须同步更新
version属性（如<config xmlns="http://example.com/v2"></config>），并在解析器中做显式校验 - CI 流程里加入验证步骤：用
xmllint --schema schema-v2.xsd config.xml --noout，失败则阻断合并 - 不要在同一个 XML 文件里混用多版本语法；需要兼容过渡期，就用
<compatibility-mode>true</compatibility-mode>开关，而不是靠注释或条件标签
Git blame 失效：某行 XML 看似没变，但 blame 显示上次修改是三个月前
这是因为 XML 格式化工具（如 IDE 自动 reformat）或 CI 构建脚本悄悄重写了整文件，导致 Git 认为「所有行都变了」，blame 链断裂。
- 禁用编辑器的「on save format」对 XML 的全局开关，改为仅对特定目录启用（如
src/main/resources/**.xml） - 在
.git-blame-ignore-revs中记录格式化提交的 hash，配合git blame -S .git-blame-ignore-revs过滤干扰 - 关键配置文件（如
application.xml）设为linguist-generated=true（写入.gitattributes），让 GitHub/GitLab 不展示 blame，避免误导
XML 的「可读性」和「可合并性」天然矛盾，靠 Git 默认行为扛不住。真正省事的做法，是把结构约束前移到提交环节——格式校验、唯一标识、拆分粒度，这些动作漏掉任何一环，后期 merge 就得靠人眼一行行对。
