带分支的Git主服务器重新基址主服务器

Question

我有以下的git结构。

            G - H - I <-feature-branch 1
          /
- A - B - C <-master
           \       
             X - Y <-feature-branch 2

我的问题是，最初我一直致力于我的主分支，而不是我的任一功能分支。现在，我的两个特征都准备好合并了，但是我的主人没有跟踪上游，所以合并是非常棘手的，在当前状态下，必须合并其中一个特征才能轻松地合并另一个特征。我想重置我的master，使其与upstream相同，并将所有更改推送到任一功能分支。另一个特性也应该是从master派生的。所以，在图形方面，我想要这样：

    G - H - I <-feature-branch 1
   /
- A <-master
   \       
    B - C - X - Y <-feature-branch 2

谢谢!

Answer 1

所以首先你必须将你的master重置为A：

git checkout master
git reset A --hard

其中，显然，A是您想要重置为的提交散列。

此时，branch-2正处于您想要的状态。尽管如此，branch-1历史记录仍然包含提交B和C。

为了重写历史，你必须在master之上以交互方式重新建立基础：

git checkout branch-1
git rebase -i master

你会用默认的git编辑器(通常是vim或nano)提示你的分支和主程序之间的提交列表。

只需删除行B和C，保存并退出即可。

现在，您将获得您设计的结果。

我希望这能帮到你。

Answer 2

既然你的功能分支具有相同的起点，并且“为了容易地合并另一个功能，两个功能中的任何一个都必须合并”，也就是说，两者都有彼此需要的东西，为什么不呢？

1. 合并功能分支1与2 (X表示主

上的X

1. 合并X至主

并在2之后。

- A - B - C <-master
           \       
             G - H - X - I - Y - I <-feature-branch X

在3点之后。

- A - B - C - G - H - X - I - Y - I <-master

Answer 3

现有的答案可能会让你达到你想要的状态；但你会不厌其烦地拼写出你的推理，所以我认为值得先检查一下假设。

您说在您当前的状态下，合并两个分支是很棘手的……但事实并非如此。开始于

            G - H - I <-feature-branch 1
          /
- A - B - C <-master
           \       
             X - Y <-feature-branch 2

将功能合并到master很容易。第一次合并可以(默认情况下)作为快进完成；即使您强制它是真正的合并而不是快进，它仍然是微不足道的；然后(无论哪种方式)第二次合并都是简单的。(唯一可能的复杂性是如果分支处于严重冲突中，在这种情况下，这种方法仍然允许以最小的努力来解决此类冲突。)

这可能会产生所需的提交拓扑，也可能不会产生；但是您还没有真正解释您希望合并后的拓扑是什么样子(或者为什么)；您只是描述了一个您认为首先需要达到的中间状态。

我的主人

没有追踪到上游

不清楚你这么说是什么意思。您的意思是本地master领先于上游吗？因为您最终会将本地和远程master分支向前移动到您创建的合并，所以基本上没有区别。

必须合并这两个要素中的任何一个，才能轻松合并另一个要素

什么事情使你那样想？根据您所描述的状态，第一次将其中任何一个合并到master将非常容易。

你说你想要达到像这样的状态

        G - H - I <-feature-branch 1
       /
... - A <-master
       \       
        B - C - X - Y <-feature-branch 2

这实际上是不可能的；G的父对象是C，您不能通过“更改”它来使其父对象成为A。相反，您可以替换它(以及从它派生的提交)，这样您就可以得到

        G' - H' - I' <-feature-branch 1
       /
... - A <-master
       \       
        B - C - X - Y <-feature-branch 2

这可能很重要，因为这意味着您将编辑feature-branch-1的历史记录。(在git中，历史编辑是一个非常有用的工具，但如果您要使用它，特别是如果其他人与您共享上游repo，则需要了解它的成本。)

但真正的问题是，从feature-branch-1的历史中删除B和C到底能给你带来什么好处？如果来自G、H或I的更改与来自B或C的更改重叠，您将在尝试执行此操作时遇到冲突；为了解决这些冲突，您将进行新的更改，这些更改将在最后将所有内容合并在一起时产生额外的冲突。即使这些更改不重叠/冲突，如果feature-branch-1中的任何内容(有意或无意地)依赖于A或B中的任何内容，那么您的分支将由失败的提交组成，这可能会阻碍未来的bug搜索。

在您希望最终的历史是什么样子时，可能还有其他考虑因素，但仅考虑到您所概述的推理，我将简单地

git checkout master
git merge feature-branch-1

这将自动工作，并将导致

... - A - B - C - G - H - I <-(feature-branch 1)(master)
               \       
                 X - Y <-feature-branch 2

然后

git merge feature-branch-2

给你

... - A - B - C - G - H - I - M <-(feature-branch 1)(master)
               \             /
                 X -------- Y <-feature-branch 2

由于所有操作都只导致分支向前移动，因此推送将干净地更新遥控器。