git多分支交叉合并冲突本质是三路合并失去清晰参照系，因merge-base退化为过早祖先导致误判；需用git merge-base --all定位最优共同祖先，并按types→config→utils顺序分层解决，慎用ours/theirs一键操作。
多分支交叉合并产生的冲突，本质不是“代码乱了”，而是 Git 在多个修改路径之间失去了清晰的参照系。三路合并算法依赖一个共同祖先，但当 feature/A、feature/B、develop 三者反复合并又各自推进时，merge-base 可能退化成很早的历史提交，导致 Git 拿一个过时的版本去比对两边改动——这时它标出的“冲突”往往看起来莫名其妙，甚至同一行被标了两次。
先定位 merge-base 是哪个提交
交叉合并最常踩的坑，是默认相信 git merge 自动选的共同祖先。实际中，git merge-base feature/A feature/B 返回的提交可能比你预期的早得多，尤其当两个 feature 都曾从 develop 合并过旧版本时。
- 用
git merge-base --all feature/A feature/B查看所有可能的共同祖先，挑时间最近、语义最合理的那个 - 如果返回多个，结合
git log --oneline --graph --all看分支交汇点，避免选到某个已废弃的临时合并提交 - 必要时可强制指定祖先：
git merge -s recursive -X ours feature/B（仅限明确知道要偏向哪边时）
把“多文件冲突”拆成单维度问题链
交叉合并常伴随 utils.js、config.json、types.ts 多个文件同时报冲突，直接打开编辑器硬啃容易漏逻辑。更有效的做法是按影响域分层处理：
- 先解决
types.ts：类型定义变动会波及其他文件，但它通常不带业务逻辑，冲突判断最干净 - 再处理
config.json：纯数据文件，冲突往往是键名重复或值覆盖，用git diff --no-index对比原始内容更直观 - 最后碰
utils.js：这里很可能存在“删除 vs 修改”类隐性冲突（比如 A 删了函数，B 改了同名函数），不能只看标记行，得查调用链
别信 “ours/theirs” 一键解决，尤其在交叉场景下
git checkout --ours 或 --theirs 在简单两分支合并中能省事，但在 feature/A ←→ develop ←→ feature/B 的三角关系里，ours 指的是当前所在分支的版本，而这个分支本身可能已经混入了其他分支的改动——它未必代表你真正想保留的语义。
- 执行前先用
git show :2:src/utils.js（基础版本）、:1:src/utils.js（ours）、:3:src/utils.js（theirs）分别导出三个版本做文本对比 - 特别警惕
CONFLICT (delete/modify)类型：Git 不会自动标 git status 会显示 “deleted by us” 或 “deleted by them”，这类必须手动确认函数是否真该删 - 如果发现某个冲突区域在三个版本里都不同，说明 merge-base 已失效，建议回退到上一步，先
git rebase develop整理 feature 分支线性历史，再合并
真正麻烦的从来不是标记怎么删，而是当你面对五个文件里分散出现的同一处逻辑变更时，得靠人脑串起它们之间的依赖和意图。这时候别省那几秒 git log -p -S "functionName"，翻一翻每个相关提交的实际改动，比凭空猜“谁该听谁的”靠谱得多。
