把开源项目新的 feature 更新到已经魔改过的自用版本上的最佳姿势是什么？

[ch2]

背景：基于某开源项目版本 v1 进行魔改得到了私有版本 v1-patch
经过若干个月后 v1 迭代升级到了 v2 ，加入了不少新的特性
那么有没有什么好的办法可以把 v1-v2 之间的 commit 妥善地移植到 v1-patch 上呢？ cherry-pick 大概率是不行的，把 v1-patch 的新 commit 导出.patch 文件给 v2 打上如何？
想请教一下这件事怎么做最好

[mercury233]

没有银弹

[dcalsky]

当然是 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

[ch2]

@dcalsky rebase 肯定成功不了的吧

[tiedan]

如果魔改的严重基本无解，前几个版本还行，到后面代码差异大了，想引入 commit 几乎是不可能的了

[dcalsky]

@ch2 你指的是有 conflict 吗？看你改动的水平啦

[Kobayashi]

重新把你的 patch 打到 v2 上。如果 v2 变动多的话一个小版本小版本的 rebase 过去。如果 v2 变动非常大属于 breaking change 可能不好搞。
最靠谱的还是找一个完全吃透这个开源项目的人来做这个事情。

[adoal]

没有银弹

[lululau]

1 楼正解，rebase 不是用来减少冲突几率的

[duke807]

直接 merge v2 ，有衝突手動解決

如果提交太多，你可以人為地把 v1 和 v2 之間做一些切分，逐一進行 merge

切分可以是在你腦海中，merge 分隔点所在的提交的 hash 值就行，或者先打 tag 標記再 merge

[duke807]

上述是不拋棄歷史提交和分支的做法
即便重新基於 v2 人肉合併你的 patch 更方便，依然可以把人肉合併好的結果直接做為上述 merge 合併流程的衝突解決的結果

如果廢棄歷史 patch 的分支沒所謂，那就直接從 v2 分支出新 patch 好了

[msg7086]

Rebase 到 v2 。（并不是说你不需要处理冲突，而是这么搞可以分阶段而且可持续。）
我自己维护的一个开源项目魔改就是这么操作的，五六年有了吧，一直到现在。

[0o0O0o0O0o]

我一般是尽量确保 v1-patch 改动都是加在新的文件里，原本的文件可能只改动若干字符，然后对 v2 人肉 patch 成 v2-patch 。因为如果上游非常活跃的话，我是非常不想改变历史 commit hash 的。我一直以为是邪道做法，看楼上大家的说法，好像也没问题？

[yk000123]

怎么楼上很多推荐 rebase 的。正常不是应该 merge 吗？ rebase 会篡改历史呀。