背景:基于某开源项目版本 v1 进行魔改得到了私有版本 v1-patch
经过若干个月后 v1 迭代升级到了 v2 ,加入了不少新的特性
那么有没有什么好的办法可以把 v1-v2 之间的 commit 妥善地移植到 v1-patch 上呢?
cherry-pick 大概率是不行的,把 v1-patch 的新 commit 导出.patch 文件给 v2 打上如何?
想请教一下这件事怎么做最好
1
mercury233 2022-02-09 18:41:48 +08:00
没有银弹
|
2
dcalsky 2022-02-09 18:42:11 +08:00
当然是 rebase upstream remote 的 v2 branch 啦。
简单写个: 先 checkout 到你的 v1-patch 然后: 1. git remote add upstream <original repo> 2. git pull upstream v2 3. git rebase upstream/v2 |
4
tiedan 2022-02-09 20:09:00 +08:00
如果魔改的严重基本无解,前几个版本还行,到后面代码差异大了,想引入 commit 几乎是不可能的了
|
6
Kobayashi 2022-02-09 22:01:15 +08:00 via Android 1
重新把你的 patch 打到 v2 上。如果 v2 变动多的话一个小版本小版本的 rebase 过去。如果 v2 变动非常大属于 breaking change 可能不好搞。
最靠谱的还是找一个完全吃透这个开源项目的人来做这个事情。 |
7
adoal 2022-02-09 22:04:48 +08:00
没有银弹
|
8
lululau 2022-02-09 22:12:22 +08:00
1 楼正解,rebase 不是用来减少冲突几率的
|
9
duke807 2022-02-10 00:49:47 +08:00 via Android
直接 merge v2 ,有衝突手動解決
如果提交太多,你可以人為地把 v1 和 v2 之間做一些切分,逐一進行 merge 切分可以是在你腦海中,merge 分隔点所在的提交的 hash 值就行,或者先打 tag 標記再 merge |
10
duke807 2022-02-10 01:01:38 +08:00 via Android
上述是不拋棄歷史提交和分支的做法
即便重新基於 v2 人肉合併你的 patch 更方便,依然可以把人肉合併好的結果直接做為上述 merge 合併流程的衝突解決的結果 如果廢棄歷史 patch 的分支沒所謂,那就直接從 v2 分支出新 patch 好了 |
11
msg7086 2022-02-10 01:35:48 +08:00 via Android
Rebase 到 v2 。(并不是说你不需要处理冲突,而是这么搞可以分阶段而且可持续。)
我自己维护的一个开源项目魔改就是这么操作的,五六年有了吧,一直到现在。 |
12
0o0O0o0O0o 2022-02-10 08:13:55 +08:00 via iPhone
我一般是尽量确保 v1-patch 改动都是加在新的文件里,原本的文件可能只改动若干字符,然后对 v2 人肉 patch 成 v2-patch 。因为如果上游非常活跃的话,我是非常不想改变历史 commit hash 的。我一直以为是邪道做法,看楼上大家的说法,好像也没问题?
|
13
yk000123 2022-02-10 08:29:28 +08:00 via iPhone
怎么楼上很多推荐 rebase 的。正常不是应该 merge 吗? rebase 会篡改历史呀。
|