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

[suikaChen]

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

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

[rainbowhu]

merge commit 本身就可以包含解决冲突的修改，倒也不用单独搞个 commit 解决冲突。不过这些倒也没这么关键

[thorneLiu]

合代码简单 没有回归测试才会搞死人

[whoosy]

我做过类似的事情，和你的相比只多不少，直接强行合并，按文件解决冲突，最后 QA 全量测试兜底，中间过程心酸不再说了

[Wetoria]

如果公用代码的部分改动不是特别大，A 切 C ，把 B 合到 C ，处理冲突。
A 和 B 项目的需求，在对应分支上单独开发完以后，往 C 合一次。
C 项目的就 C 项目继续开发。

实在不行，按照前面说的 Linus 合并法搞。

[debuggeeker]

直接合，有冲突，有冲突就解决，这个时候找写代码的人解决，怎么把功能合起来，解决完冲突全部测试跑一次

[mark2025]

squash 压缩一次性合并

[BinCats]

分享下我的做法，idea 本地打开代码，选择代码文件夹，compare with branch ，人工简单复核一下，合并完成之后再操作一次看是否还有差异。2.git 的 cherry pick 功能