处理 Git 冲突前，我会先用 Mergiraf 把语法树合并和人工复核分层
多人同时改同一段代码时，Git 的冲突标记通常只能告诉我们哪几行撞上了。真正耗时间的地方在后面：函数有没有被重复插入，列表项顺序有没有被误改，import 和配置块能不能自动整理，最后还要靠人把每一段冲突重新读一遍。Mergiraf 的价值在这里很清楚，它把三方合并提升到语法树层面，先尝试理解代码结构，再把仍然不确定的片段交给开发者复核。
从三方冲突、语法树解析、结构化合并到人工复核和测试的流程示意 来源：Codex image generation
适合放在哪里
我不会把它直接当成团队唯一的合并答案。更稳的做法是把 Mergiraf 放在本地合并和 CI 预检之间，作为一层候选解算器。开发者拉取分支后先用普通 Git 进入合并流程，遇到支持语言里的结构化冲突时交给 Mergiraf 处理。它能把很多行级冲突收敛成可读结果，剩下的部分再回到人工 review。
这个边界很重要。它擅长处理代码结构、数组项、导入块、相邻函数和格式化后的相同意图。它不负责判断业务语义，例如两个分支都改了权限策略，或者一个分支删除了某个字段，另一个分支继续依赖它。自动合并后的结果仍然要跑单元测试、类型检查和关键路径回归。
落地时先收紧规则
第一步是先在个人仓库或低风险模块试用，不要一开始全仓启用。官方文档建议配合 Git 的 diff3 冲突样式，这样工具能拿到 base、ours 和 theirs 三份信息。团队可以先让几位经常处理冲突的开发者记录三类样本：完全自动解决、自动解决但需要人工微调、仍然保留冲突。
第二步是给语言范围设白名单。Mergiraf 支持多种常见语言和配置格式，但项目里总会有生成文件、锁文件、快照文件和特殊 DSL。对这些文件，继续使用原来的合并策略反而更可控。可以通过仓库规则把高风险路径排除，让工具只接手源码、配置和结构稳定的文本。
第三步是把报告接进 review。我的建议是把合并结果分成三层看：第一层是工具自动整理的结构冲突，第二层是仍然带冲突标记的片段，第三层是测试失败暴露的语义问题。这样评审者不会把精力耗在逗号、括号和 import 顺序上，可以专注看行为是否被改变。
我还会把回退路径写清楚。只要自动合并后的文件看起来可疑，或者测试暴露出不相关的行为变化，就恢复到普通冲突标记重新处理。每次引入新语言、新目录或新生成物，也先收集真实冲突样本，再决定是否加入白名单。
团队收益
这类工具最适合长期维护的代码库。分支多、改动小、冲突频繁时，它能减少重复劳动，让合并流程从逐行猜测转成结构化复核。对 AI 生成补丁也有帮助，因为多个补丁同时改同一个组件时，冲突常常出现在相邻函数和配置数组里。先用语法树合并清掉机械噪音，再用测试和人工判断守住语义边界，整体成本会更低。