Question

所以问题是这样的：假设我有一个 master ，然后从该状态开始发展到分支A ，但随后我从分支A 创建了PR 大师，然后我开始在分支A 上开发一些东西，因为我需要对该分支 A 进行一些更改，因此我创建了< strong> B支。

a -- b -- c  ---- h       <-- Master
           \
           d -- e           <-- Branch A
                 \
                  f -- g     <-- Branch B

这是我的当前状态，出于某种原因，我必须在分支A中进行一些更改，因此我继续创建一些提交，最后将分支A合并到主服务器中。到那时，我将需要重新设置分支B的基础才能从分支A获得最新的提交。我应该怎么做，这就是我的想象。

a -- b -- c  ---     -- h       <-- Master
           \          /
           d -- e -- i     <-- Branch A
                      \
                       f -- g     <-- Branch B

Answer 1

将提交i添加到Branch-A后，您将得到：

a -- b -- c ------ h       <-- Master
           \
            d -- e -- i     <-- Branch-A
             \
              f -- g     <-- Branch-B

（请记住，您的原始图形包含提交h，因此它必须在合并发生之前。）进行实际合并会产生新的提交j：

a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i     <-- Branch-A
             \
              f -- g     <-- Branch-B

此合并是必需的，因为必须保留现有的提交h，而新的提交d-e-i可以从master的顶端访问：这需要合并提交j，其父母是两个现有提交h和i。（如果h不存在，则可能会进行快进操作：该操作会更改结果图形的形状，因此其效果会在其余答案中波动。我们假设h确实存在，并且/或仍然强制执行非快进合并。）

这时，您现在有了选项，其中删除的名称Branch-A完全（随时），还有 option ，将现有提交f和g复制到新改进的提交f'和g'中。这就是您要询问的基准。

应该为它们重新定基吗？这是一个很难的问题。但是，只要其他所有人都同意可以放弃原始提交f和g来支持新改进的f'和g'，就可以了。这也可能使事情以后变得更漂亮。如果您决定不对它们进行重新设置，那么如何解决这个问题就没有意义了。

如果要做决定为其重新定基，则下一个问题需要是：在哪个目标提交上？ f'应该在i之后还是应该在j之后？让我们来绘制两种情况：

(option 1: after i)

a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i     <-- Branch-A
             \         \
              \         f' -- g'   <-- Branch-B
               \
                f -- g   [abandoned]

(option 2: after j)

                          f' -- g'   <-- Branch-B
                         /
a -- b -- c ------ h -- j       <-- Master
           \           /
            d -- e -- i
             \
              f -- g  [abandoned]

要使选项2发生，请运行：

git checkout Branch-B
git rebase Master

（我喜欢在这里使用两个单独的命令，但是您可以根据需要拼写此git rebase Master Branch-B：额外的Branch-B参数使git rebase首先运行git checkout 。）请注意，我已经删除了名称Branch-A：在这里我们不需要它。此时您可能已经删除或可能尚未删除它；如果尚未删除，则可以稍后删除它。

要使选项1发生，请运行：

git checkout Branch-B
git rebase Branch-A

这次，我们需要 name Branch-A来轻松找到提交j的哈希ID。因此，如果您想使选项1发生，并且不想运行git log并剪切和粘贴哈希ID，请至少保持名称Branch-A到此为止。重新设置完成后，我们不再需要名称Branch-A，现在可以安全删除了。

技术上，我们在重新设置基准之前也不需要它，因为我们可以随时查找j的哈希ID：git log Master从{{1开始}}并向我们展示，然后向我们展示j或h之一，最终我们看到i并因此看到其哈希ID。因此，无论如何我们都很难找到它。但是，如果您保留一段时间，我们就没有没有这样做。

注意：：如果您使用GitHub的“ rebase and merge”或“ squash and merge” clicky按钮，则不会执行标准合并。相反，它们 copy 提交到新的副本，类似于重新设置基准。也就是说，他们将为您尝试合并的提交制作新的并且可能经过改进的副本。在这种情况下，您自己的现有名称中的再也找不到正确的提交哈希ID ，因为所有您的名称仍然会记住您的原始提交以及它们的哈希ID，而不是GitHub将会创建的副本/新提交。因此，如果您使用使用GitHub的高级操作，则必须运行i才能从GitHub中获取的新提交，然后使用其他名称或原始提交哈希ID；您应该尽快放弃或修改自己的分支机构名称，以免混淆哪些提交是原始副本，哪些是新的，据说是经过改进的副本。（是提交git fetch的原始文件，还是f9131d9？70abf32c与a31cf2a呢？哈希ID看起来完全是随机的，将它们保持直是很不好的……不是很有趣。）

Answer 2

这种方法是“过度支配”的。只需开发与其中的分支A相关的新功能。不要创建分支B。如果新功能进入master-提交分支A并合并到master。

如何从主站的另一个功能分支重新建立分支或合并分支

2 个答案: