我们已经分叉了一个庞大的项目,因为我们想要提供它的修改版本。我们绝对打算继续关注上游,每当他们发布新的稳定版本时,我们就会对其进行更改。
但是,我不确定如何在版本控制方面做到最好。这就是我们开始做的事情(如果答案是关于Git或Mercurial,我不介意,因为我熟悉两者,但我会在这里谈谈Git。):
foo
之上创建一个名为我们产品的新分支,让我们说master
。foo
分支中提交所有更改。(我相信这称为"供应商分支"。)
现在我们必须得到最新的上游变化。第一步自然是将上游变化拉入master
,到目前为止我们还没有触及。那么呢?
我真正想做的是在foo
之上重新定位master
。但是,由于我们已将foo
分支推送到我们的存储库并正在进行协作,因此git push --force
似乎不是一个选项。
我看到两种选择:
master
合并到foo
。master
创建新的供应商分支,将旧版本的所有更改合并到该分支中。两者看起来都不理想:
foo
的历史记录最终将与master
交织在一起,而不是与其隔离。当发生合并冲突时,我们必须在合并期间修改上游提交,而不是我们自己的提交。
我认为这可以按照需要运作。但是,为每个新版本创建一个新分支似乎是一个黑客,人们总是要检查他们是否正确...
还有其他选择吗?在Git或Mercurial中最好的方法是什么?
答案 0 :(得分:0)
这取决于你的变化有多广泛和将要变得多大。
我会说很多,因为我对此更为熟悉:
如果在上游默认分支上只应用了一小组补丁,那么当您提取更改时,您可以始终在上游提示的顶部重新设置补丁系列/变更集。在这种情况下,evolve扩展可能会派上用场。
或者,可能优先(我不太清楚为什么合并方法应该有问题):它取决于您合并的头部以及您用作基础的头部:提交您的更改。然后拉上游。更新到上游提示并合并包含本地更改的头部。然后,您只需要对已更改的头进行修改 - 而不是对上游提交进行修改。使用书签来区分(匿名)头部,它们都是默认分支的一部分。