从Feature/A切出的Feature/B合并到master出现大量冲突，原因及解决方法是什么？

1. 最核心的诱因是Feature/A合并到master时使用了压缩合并（squash merge）：squash合并不会保留Feature/A的原始提交历史（提交3、4、5）到master分支，只会在master生成一个包含所有Feature/A改动的全新独立提交（也就是你提到的提交点9）。这就导致Git执行git merge-base --all HEAD master判断最近共同祖先时，无法识别到Feature/B的根提交（提交5）属于master的祖先链，只能追溯到两个分支最早的分叉点提交2。
2. Git合并逻辑是对比共同祖先到两个分支最新提交的所有差异：而Feature/B是基于Feature/A的提交5创建的，本身已经包含了Feature/A的全量改动，master上又有squash生成的Feature/A改动，Git会将这两部分来源不同但内容高度重合的改动判定为冲突，最终出现大量无意义的冲突提示。
3. 即使你用的是普通非快进合并（--no-ff）合并Feature/A到master，如果合并时手动调整过大量冲突代码，导致master上的合并提交内容和Feature/A提交5的原始内容差异较大，也会触发类似的重复冲突。

• 团队合并特性分支到主干时优先使用普通非快进合并（--no-ff），不要默认开启squash merge：普通合并会保留完整的提交祖先链，Git可以正确识别Feature/B的祖先包含Feature/A的提交，合并基会定位到提交5，只会对比提交5之后Feature/B的独有改动和master的改动，冲突只会出现在两边确实同时修改的部分。
• 如果团队规范要求必须用squash merge合并特性分支：在父分支（Feature/A）合并到master之后，需要先给子分支（Feature/B）执行变基操作，命令为git rebase --onto master <Feature/A合并前的最后一个提交ID> Feature/B，将Feature/B的独有提交直接嫁接到最新master上，再合并就不会出现重复改动的冲突。
• 日常开发尽量避免多层嵌套切分支：所有特性分支优先直接从最新的master拉取，不要从其他未合并到master的特性分支上再切新分支，从根源上规避这类父分支合并后子分支冲突的问题。
• 如果已经触发了这类冲突，不想逐个手动解决，可以先在Feature/B分支执行git merge -s ours feature/A，告知Git已经完全接受Feature/A的所有改动，不需要再合并这部分内容，之后再执行git merge master就可以过滤掉大部分重复冲突。

内容的提问来源于stack exchange，提问作者Aiman