请教各位关于 Git 合并的问题
现在我手头上有一个项目,A 和 B 两个分支,两者都是从 2.0 版本分支衍生出于的,也就是处于同一起点。
两个分支后续独立开发迭代,两者的需求代码最多 10%的相似度。
经过半年的开发之后,现在两者相差 200+个 commit ,500+个更改。
现在产品有需求,需要以 A 分支为基底,将 B 分支的所有内容合入,保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并,感觉都不太好,没办法保证最终的合并结果。
各位有没有什么比较好的合并方式?
没啥好办法, 相差太大了,抽出来两天搞吧,光看到我就觉得神经要崩溃了。
感觉跟 git 没关,差异太大,你也合不了吧,手动粘贴复制吧
以 20 commit 作为单位 手动 cheery pick 验证阶段性功能没问题后再 rebase ?
我觉得只有 merge 合并,然后再解决冲突了。你们公司的开发模式有问题,时间跨度这么大,中途没有任何同步代码的过程,最后还是要苦了自己。
你把所有的合并方式都否了让人咋回答....
人工手动迁移代码吧,没人能保证合并过来的代码能正常跑(先不说跑起来,解决冲突估计都一脑袋汗)
产品一开始说的就是不合并,结果后面又要合,真是脑袋痛。
也不是,只是抛砖引玉。兄弟有好想法都可以提,在不在我的方式范围里都可以的。
确实,合并这么大量的 commit 我觉得 git 的合并机制都不太可靠了。
人工迁移吧。两个分支边对比边改快一点。可能也别想 cherry 了,一个 cherry 一个不吱声。
我们去年 10 月份 fork 并同时维护两个版本,两个版本之间的功能现在靠人工 diff 合并后手动提交 commit
建议重新整理需求和功能,然后基于一个最贴近完整版的版本重构开发,参考而不合并之前的代码
是一个思路。确实强行合并风险太高了。
jetbrains git log ,B 分支 commit 全选,挨个文件 cherry pick 。
冲突就 merge 一次性解决,rebase 冲突了的话,通常需要反复处理同一个位置的冲突,你会崩溃的
要不,挑一个分支,重写?
主要是有没有单元测试和 api 测试,不然手动整基本崩了打地鼠一样
如果写了完整单元测试,没啥大问题,大胆的合并吧。有问题一个文件一个文件解决。合并完了跑单测,有问题再去改实现代码。我们有项目 40 多个不同分支,因为是基于一个项目私有化部署了几十个项目,后来实在没法维护了,也合并过一次,搞了一周左右。
我只知道用了 rebase 你肯定会想死
光是这一句想法:“需要以 A 分支为基底,将 B 分支的所有内容合入,保证最终分支包含 AB 分支的所有更改。”
客观事实上能不能做到还是两说呢。
和双胞胎谈恋爱,你想让大的当成小的,小的变成大的,都没问题,但是你想大小一起的时候,那是不可能的
哈哈哈哈 好形象的比喻
合理哈哈哈哈。
目前看下来还是手动按需求来合并比较靠谱一些。
只是 commit 记录就只能放弃了。
我也是觉得头皮发麻才放弃。
差别太大的话,感觉通过 commit 维度或者文件维度都很难操作,不如对照着功能点和代码进行重写逻辑了...能用的代码人工复制过来
应该说按需求手动重写,然后复用代码。
是的,目前看下来只有这种方案风险比较低,可操作性也还可以。
从 A 分支拉一个新分支 C;
先试试将 B merge to C,如果冲突太多密密麻麻头疼就取消;
然后 试试 cherry 命令,根据提交记录慢慢合;
年初买了一台小米 11 青春活力版,刷了 lineageos 系统。半年多使用下来还挺稳定的,没有乱七八糟的东西,基本上能符合我的预期。唯一的毛病就是这玩意儿屏幕太伤眼了,每次…
漏洞 CVE-2024-11477 受影响版本 24.06 请及时更新到最新版, 官网: 7-zip.org/ 我用的是 24.08 感谢提醒。用的也是 24.08 …
还记得以前和大家提到过的《各种流行的编程风格》吗?有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例,让我们看看那个流行的编程风格是实践是什么样的。下面的这个实…