请教各位关于 Git 合并的问题

现在我手头上有一个项目，A 和 B 两个分支，两者都是从 2.0 版本分支衍生出于的，也就是处于同一起点。
两个分支后续独立开发迭代，两者的需求代码最多 10%的相似度。
经过半年的开发之后，现在两者相差 200+个 commit ，500+个更改。

现在产品有需求，需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并，感觉都不太好，没办法保证最终的合并结果。
各位有没有什么比较好的合并方式？

https://i.imgur.com/Iy0taMy.png 没啥好办法， 相差太大了，抽出来两天搞吧，光看到我就觉得神经要崩溃了。

以 20 commit 作为单位 手动 cheery pick 验证阶段性功能没问题后再 rebase ？

我觉得只有 merge 合并，然后再解决冲突了。你们公司的开发模式有问题，时间跨度这么大，中途没有任何同步代码的过程，最后还是要苦了自己。

你把所有的合并方式都否了让人咋回答....

人工手动迁移代码吧，没人能保证合并过来的代码能正常跑（先不说跑起来，解决冲突估计都一脑袋汗）

@mangoDB 产品一开始说的就是不合并，结果后面又要合，真是脑袋痛。

@NessajCN 也不是，只是抛砖引玉。兄弟有好想法都可以提，在不在我的方式范围里都可以的。

@willxiang 确实，合并这么大量的 commit 我觉得 git 的合并机制都不太可靠了。