这是一个创建于 196 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在我手头上有一个项目，A 和 B 两个分支，两者都是从 2.0 版本分支衍生出于的，也就是处于同一起点。
两个分支后续独立开发迭代，两者的需求代码最多 10%的相似度。
经过半年的开发之后，现在两者相差 200+个 commit ，500+个更改。
现在产品有需求，需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并，感觉都不太好，没办法保证最终的合并结果。
各位有没有什么比较好的合并方式？
两个分支后续独立开发迭代，两者的需求代码最多 10%的相似度。
经过半年的开发之后，现在两者相差 200+个 commit ，500+个更改。
现在产品有需求，需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并，感觉都不太好，没办法保证最终的合并结果。
各位有没有什么比较好的合并方式？
 | 1 xiaofsu 196 天前  没啥好办法， 相差太大了，抽出来两天搞吧，光看到我就觉得神经要崩溃了。 |
 | 2 EastLord 196 天前  1 感觉跟 git 没关，差异太大，你也合不了吧，手动粘贴复制吧 |
 | 3 calvinHxx 196 天前 以 20 commit 作为单位 手动 cheery pick 验证阶段性功能没问题后再 rebase ？ |
 | 4 mangoDB 196 天前 我觉得只有 merge 合并，然后再解决冲突了。你们公司的开发模式有问题，时间跨度这么大，中途没有任何同步代码的过程，最后还是要苦了自己。 |
 | 5 NessajCN 196 天前 1 你把所有的合并方式都否了让人咋回答.... |
 | &nbs; 6 willxiang 196 天前 人工手动迁移代码吧，没人能保证合并过来的代码能正常跑（先不说跑起来，解决冲突估计都一脑袋汗） |
 | 10 linzyjx 196 天前 人工迁移吧。两个分支边对比边改快一点。可能也别想 cherry 了，一个 cherry 一个不吱声。 我们去年 10 月份 fork 并同时维护两个版本，两个版本之间的功能现在靠人工 diff 合并后手动提交 commit |
 | 11 KagurazakaNyaa 196 天前 2 建议重新整理需求和功能，然后基于一个最贴近完整版的版本重构开发，参考而不合并之前的代码 |
 | 12 suikaChen OP @XiLingHost 是一个思路。确实强行合并风险太高了。 |
 | 13 wolfie 196 天前 jetbrains git log ，B 分支 commit 全选，挨个文件 cherry pick 。 |
 | 14 hwdq0012 196 天前 冲突就 merge 一次性解决，rebase 冲突了的话，通常需要反复处理同一个位置的冲突，你会崩溃的 |
 | 15 ho121 196 天前 via Android 要不，挑一个分支，重写？ |
 | 16 guanzhangzhang 196 天前 主要是有没有单元测试和 api 测试，不然手动整基本崩了打地鼠一样 |
 | 17 thinkershare 196 天前 如果写了完整单元测试，没啥大问题，大胆的合并吧。有问题一个文件一个文件解决。合并完了跑单测，有问题再去改实现代码。我们有项目 40 多个不同分支，因为是基于一个项目私有化部署了几十个项目，后来实在没法维护了，也合并过一次，搞了一周左右。 |
 | 18 follower 196 天前 我只知道用了 rebase 你肯定会想死  |
 | 19 Yuanlaoer 196 天前 光是这一句想法：“需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。” 客观事实上能不能做到还是两说呢。 |
 | 20 v1 196 天前 1 和双胞胎谈恋爱，你想让大的当成小的，小的变成大的，都没问题，但是你想大小一起的时候，那是不可能的 |
| 23 suikaChen OP 目前看下来还是手动按需求来合并比较靠谱一些。 只是 commit 记录就只能放弃了。 |
 | 25 luckyrayyy 196 天前 差别太大的话，感觉通过 commit 维度或者文件维度都很难操作，不如对照着功能点和代码进行重写逻辑了...能用的代码人工复制过来 |
| 27 suikaChen OP @luckyrayyy 是的，目前看下来只有这种方案风险比较低，可操作性也还可以。 |
 | 28 TONYXUELI 196 天前 从 A 分支拉一个新分支 C; 先试试将 B merge to C,如果冲突太多密密麻麻头疼就取消; 然后 试试 cherry 命令,根据提交记录慢慢合; |
 | 29 lanmiao 196 天前 “相差 200+个 commit ，500+个更改” 其实也没多少代码。 只要不是让你明天上线，那直接把 B 到 mergeA 或拉个 C 分支再合并都行，然后该改的改，该屏蔽的屏蔽，调通代码转测试就行了。 |
 | 30 red666 196 天前 via Android 能不能不合并 |
 | 31 dadhexd123 196 天前 哪个公司，避雷一下 |
 | 32 lovelylain 196 天前 via Android merge ，差异太大就别想着 rebase 和 cherry pick 了 |
 | 33 itechify PRO clone 下来试试，A ，B 分支都先各自切出来为 A1 ，B1 分支作为演练。A1 分支在 2.0 后 rebase /squash 合并下成一次提交，B2 也同样操作。这时候 A1 和 B1 只相差一次提交，文件会差异很大，B1 试试直接 merge 过去 A1 ，解决冲突。 |
 | 34 callv 195 天前 A 、B 分支选一个代码变更基于 2.0 版本较少的分支，提一个 Pull Request 到 2.0 分支。这时候可以看到 file changes ，然后按文件修改记录挨个的塞到另一个分支上。 |
 | 35 apuslilie 195 天前 类似这种需求是不是比较适合人工智能来搞，毕竟代码已经有了，只是一点一点的迁移过去。 |
 | 36 forcecharlie 195 天前 我建议可以使用 git reset 把 200 多个 commit 搞成一个，再去解决冲突进行合并，这个实际上和普通合并是一样的，只是能简化合并（比如分支有反复合并的情况等等），当然都需要解决冲突。 当然还有 cherry-pick 这样的机制，还有 diff patch 这样的机制。甚至手动 copy 目录/文件 |
 | 37 ooee2016 195 天前 200+的 commit ，那只有武力解决了，谁打输了谁负责合并解决冲突 |
 | 38 fawkes 195 天前 最理想的方式就是手动合并，没有捷径 |
 | 39 minami 195 天前 建议使用 Linus 合并法，  -->在 2002 年以前，世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus ，然后由 Linus 本人通过手工方式合并代码 |
| 40 suikaChen OP 刚刚尝试 merge 了一下，自动合并了 122 个文件，有 37 个文件有冲突。 冲突的文件数量看起来还可以。 打算以 A 分支 为基底，将这 37 个文件手动合并，提交一个 commit ，提完之后再 merge B 分支一遍，保证合并到所有代码并且没有冲突。 兄弟们觉得怎么样？ |
 | 41 rainbowhu 195 天前 merge commit 本身就可以包含解决冲突的修改，倒也不用单独搞个 commit 解决冲突。不过这些倒也没这么关键 |
 | 42 thorneLiu 195 天前 via Android 合代码简单 没有回归测试才会搞死人 |
 | 43 whoosy 195 天前 我做过类似的事情，和你的相比只多不少，直接强行合并，按文件解决冲突，最后 QA 全量测试兜底，中间过程心酸不再说了 |
 | 44 Wetoria 195 天前 如果公用代码的部分改动不是特别大，A 切 C ，把 B 合到 C ，处理冲突。 A 和 B 项目的需求，在对应分支上单独开发完以后，往 C 合一次。 C 项目的就 C 项目继续开发。 实在不行，按照前面说的 Linus 合并法搞。 |
 | 45 debuggeeker 194 天前 直接合，有冲突，有冲突就解决，这个时候找写代码的人解决，怎么把功能合起来，解决完冲突全部测试跑一次 |
 | 46 mark2025 194 天前 squash 压缩一次性合并 |
 | 47 BinCats 194 天前 分享下我的做法，idea 本地打开代码，选择代码文件夹，compare with branch ，人工简单复核一下，合并完成之后再操作一次看是否还有差异。2.git 的 cherry pick 功能 |
Select Language