如何在Git / Mercurial中处理跟随上游的fork?

时间:2015-01-19 10:40:58

标签: git mercurial dvcs

我们已经分叉了一个庞大的项目,因为我们想要提供它的修改版本。我们绝对打算继续关注上游,每当他们发布新的稳定版本时,我们就会对其进行更改。

但是,我不确定如何在版本控制方面做到最好。这就是我们开始做的事情(如果答案是关于Git或Mercurial,我不介意,因为我熟悉两者,但我会在这里谈谈Git。):

  1. 克隆上游项目
  2. foo之上创建一个名为我们产品的新分支,让我们说master
  3. foo分支中提交所有更改。
  4. (我相信这称为"供应商分支"。)

    现在我们必须得到最新的上游变化。第一步自然是将上游变化拉入master,到目前为止我们还没有触及。那么呢?

    我真正想做的是在foo之上重新定位master。但是,由于我们已将foo分支推送到我们的存储库并正在进行协作,因此git push --force似乎不是一个选项。

    我看到两种选择:

    1. master合并到foo
    2. 根据master创建新的供应商分支,将旧版本的所有更改合并到该分支中。
    3. 两者看起来都不理想:

      1. foo的历史记录最终将与master交织在一起,而不是与其隔离。当发生合并冲突时,我们必须在合并期间修改上游提交,而不是我们自己的提交。

      2. 我认为这可以按照需要运作。但是,为每个新版本创建一个新分支似乎是一个黑客,人们总是要检查他们是否正确...

      3. 还有其他选择吗?在Git或Mercurial中最好的方法是什么?

1 个答案:

答案 0 :(得分:0)

这取决于你的变化有多广泛和将要变得多大。

我会说很多,因为我对此更为熟悉:

如果在上游默认分支上只应用了一小组补丁,那么当您提取更改时,您可以始终在上游提示的顶部重新设置补丁系列/变更集。在这种情况下,evolve扩展可能会派上用场。

或者,可能优先(我不太清楚为什么合并方法应该有问题):它取决于您合并的头部以及您用作基础的头部:提交您的更改。然后拉上游。更新到上游提示并合并包含本地更改的头部。然后,您只需要对已更改的头进行修改 - 而不是对上游提交进行修改。使用书签来区分(匿名)头部,它们都是默认分支的一部分。