人工迁移吧。两个分支边对比边改快一点。可能也别想 cherry 了，一个 cherry 一个不吱声。 我们去年 10 月份 fork 并同时维护两个版本，两个版本之间的功能现在靠人工 diff 合并后手动提交 commit

建议重新整理需求和功能，然后基于一个最贴近完整版的版本重构开发，参考而不合并之前的代码

@XiLingHost 是一个思路。确实强行合并风险太高了。

jetbrains git log ，B 分支 commit 全选，挨个文件 cherry pick 。

冲突就 merge 一次性解决，rebase 冲突了的话，通常需要反复处理同一个位置的冲突，你会崩溃的

要不，挑一个分支，重写？

主要是有没有单元测试和 api 测试，不然手动整基本崩了打地鼠一样

如果写了完整单元测试，没啥大问题，大胆的合并吧。有问题一个文件一个文件解决。合并完了跑单测，有问题再去改实现代码。我们有项目 40 多个不同分支，因为是基于一个项目私有化部署了几十个项目，后来实在没法维护了，也合并过一次，搞了一周左右。

我只知道用了 rebase 你肯定会想死 https://i.imgur.com/MA8YqTP.png

光是这一句想法：“需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。” 客观事实上能不能做到还是两说呢。