这是一个创建于 1036 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：基于某开源项目版本 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 会篡改历史呀。
|
Select Language