Question

我具有以下git结构。

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

我的问题是，最初我一直在提交给我的master分支，而不是我的任何功能分支。现在，我的两个功能都准备好合并，但是我的主设备没有跟踪上游，因此合并非常棘手，在当前状态下，必须合并其中的两个功能才能轻松合并其他功能。我想将我的母版重置为与上游相同，并将所有更改推送到任一功能分支。其他功能也应从master派生。因此，以图形方式来说，我想拥有这个：

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

谢谢！

Answer 1

因此，首先您必须将主服务器重置为A：

git checkout master
git reset A --hard

显然A是要重置为的提交哈希。

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

要重写历史记录，您必须以交互方式基于主目录重新构建：

git checkout branch-1
git rebase -i master

系统会提示您使用默认的git编辑器（通常是vim或nano）在分支和主节点之间的提交列表。

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

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

我希望这会有所帮助。

Answer 2

由于您的要素分支具有相同的起点，并且“必须合并两个要素才能轻松地合并另一个要素”，即，两个要素之间都需要彼此提供东西，为什么不这样做：

将要素分支1与2合并（X供参考）
在主服务器上重新建立X
将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分支都移到您创建的合并中，因此基本上没有什么区别。

这两个功能必须合并才能轻松合并另一个功能

您怎么认为呢？从您描述的状态开始，将其中一个与G - H - I <-feature-branch 1 / ... - A <-master \ B - C - X - Y <-feature-branch 2进行第一次合并将非常容易。

您说您想进入类似状态

这实际上是不可能的； C的父级是A，您不能对其进行“更改”以使其父级G' - H' - I' <-feature-branch 1 / ... - A <-master \ B - C - X - Y <-feature-branch 2。相反，您将替换它（以及从它派生的提交），以便获得

feature-branch-1

这可能很重要，因为这意味着您将编辑git的历史记录。（历史记录编辑是B中一个非常有用的工具，但是如果要使用它，确实需要花费一些成本，尤其是在其他人与您共享上游存储库的情况下。）

但是真正的问题是，从C的历史中删除feature-branch-1和G到底能给您带来什么？如果H，I或B的更改与C或feature-branch-1的更改重叠，则在尝试执行此操作时会发生冲突；为了解决这些冲突，您将进行新的更改，这些更改将在最终将所有内容重新合并在一起时产生更多的冲突。即使这些更改没有重叠/冲突，即使A中的任何内容（有意或以其他方式）依赖于B或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

给你

list

由于所有操作都导致分支仅向前移动，因此按下即可干净地更新遥控器。

Git管理员对具有分支机构的管理员进行了重新设置

3 个答案: