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

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

现在产品有需求,需要以 A 分支为基底,将 B 分支的所有内容合入,保证最终分支包含 AB 分支的所有更改。
目前想过分版本合并、以 commit 为单位合并、merge 直接合并、rebase 合并,感觉都不太好,没办法保证最终的合并结果。
各位有没有什么比较好的合并方式?
4939 次点击
所在节点    git
47 条回复
rainbowhu
2025 年 3 月 28 日
merge commit 本身就可以包含解决冲突的修改,倒也不用单独搞个 commit 解决冲突。不过这些倒也没这么关键
thorneLiu
2025 年 3 月 28 日
合代码简单 没有回归测试才会搞死人
whoosy
2025 年 3 月 28 日
我做过类似的事情,和你的相比只多不少,直接强行合并,按文件解决冲突,最后 QA 全量测试兜底,中间过程心酸不再说了
Wetoria
2025 年 3 月 28 日
如果公用代码的部分改动不是特别大,A 切 C ,把 B 合到 C ,处理冲突。
A 和 B 项目的需求,在对应分支上单独开发完以后,往 C 合一次。
C 项目的就 C 项目继续开发。

实在不行,按照前面说的 Linus 合并法搞。
debuggeeker
2025 年 3 月 29 日
直接合,有冲突,有冲突就解决,这个时候找写代码的人解决,怎么把功能合起来,解决完冲突全部测试跑一次
mark2025
2025 年 3 月 29 日
squash 压缩一次性合并
BinCats
2025 年 3 月 29 日
分享下我的做法,idea 本地打开代码,选择代码文件夹,compare with branch ,人工简单复核一下,合并完成之后再操作一次看是否还有差异。2.git 的 cherry pick 功能

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

https://study.congcong.us/t/1121586

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

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

© 2021 V2EX