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

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

现在产品有需求，需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并，感觉都不太好，没办法保证最终的合并结果。
各位有没有什么比较好的合并方式？
3309 次点击
所在节点    git
47 条回复
xiaofsu
72 天前
没啥好办法， 相差太大了，抽出来两天搞吧，光看到我就觉得神经要崩溃了。
EastLord
72 天前
感觉跟 git 没关，差异太大，你也合不了吧，手动粘贴复制吧
calvinHxx
72 天前
以 20 commit 作为单位 手动 cheery pick 验证阶段性功能没问题后再 rebase ？
mangoDB
72 天前
我觉得只有 merge 合并，然后再解决冲突了。你们公司的开发模式有问题，时间跨度这么大，中途没有任何同步代码的过程，最后还是要苦了自己。
NessajCN
72 天前
你把所有的合并方式都否了让人咋回答....
willxiang
72 天前
人工手动迁移代码吧，没人能保证合并过来的代码能正常跑（先不说跑起来，解决冲突估计都一脑袋汗）
suikaChen
72 天前
@mangoDB 产品一开始说的就是不合并，结果后面又要合，真是脑袋痛。
suikaChen
72 天前
@NessajCN 也不是，只是抛砖引玉。兄弟有好想法都可以提，在不在我的方式范围里都可以的。
suikaChen
72 天前
@willxiang 确实，合并这么大量的 commit 我觉得 git 的合并机制都不太可靠了。
linzyjx
72 天前
人工迁移吧。两个分支边对比边改快一点。可能也别想 cherry 了，一个 cherry 一个不吱声。
我们去年 10 月份 fork 并同时维护两个版本，两个版本之间的功能现在靠人工 diff 合并后手动提交 commit
XiLingHost
72 天前
建议重新整理需求和功能，然后基于一个最贴近完整版的版本重构开发，参考而不合并之前的代码
suikaChen
72 天前
@XiLingHost 是一个思路。确实强行合并风险太高了。
wolfie
72 天前
jetbrains git log ，B 分支 commit 全选，挨个文件 cherry pick 。
hwdq0012
72 天前
冲突就 merge 一次性解决，rebase 冲突了的话，通常需要反复处理同一个位置的冲突，你会崩溃的
ho121
72 天前
要不，挑一个分支，重写？
guanzhangzhang
72 天前
主要是有没有单元测试和 api 测试，不然手动整基本崩了打地鼠一样
thinkershare
72 天前
如果写了完整单元测试，没啥大问题，大胆的合并吧。有问题一个文件一个文件解决。合并完了跑单测，有问题再去改实现代码。我们有项目 40 多个不同分支，因为是基于一个项目私有化部署了几十个项目，后来实在没法维护了，也合并过一次，搞了一周左右。
follower
72 天前
我只知道用了 rebase 你肯定会想死
Yuanlaoer
72 天前
光是这一句想法：“需要以 A 分支为基底，将 B 分支的所有内容合入，保证最终分支包含 AB 分支的所有更改。”
客观事实上能不能做到还是两说呢。
kk2syc
72 天前
和双胞胎谈恋爱，你想让大的当成小的，小的变成大的，都没问题，但是你想大小一起的时候，那是不可能的

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://yangjunhui.monster/t/1121586

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX