当分支分支合并时会发生什么

Question

我有一个问题，在 Git Pro 书中找不到答案。

假设我创建了branchAoff master，做了一些更改，提交并推送了拉取请求。我很确定这个分支会在某个时候合并到origin/master，但我想根据提交的更改创建进一步的开发branchB。branchA

问题是branchB何时branchA合并会发生什么？

我的看法是，如果拉取请求批准者合并branchA，那么我的branchB拉取请求将已经包含提交branchA，并且 diff 将有效地仅显示branchA和之间的更改branchB

但是，如果尚未合并，拉取请求branchB将显示两个分支的更改，并且由审批者决定合并branchA然后branchB或仅合并branchB。

请纠正我的推理

Answer 1

你遇到过这样的情况：

                       branch-A
                          v
              1---2---3---4
             /
O---O---O---O
            ^
          master

然后你这样做了：

                       branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /
O---O---O---O
            ^
          master

总结一下目前的状态：

• A 对 master 的拉取请求将显示 A 和 master 之间的差异，即有效提交 1-4
• B 到 master 的拉取请求将显示 B 和 master 之间的差异，这实际上提交了 1-8，因此包括 A 中尚未合并到 master 中的所有更改

如果您现在决定完成 A 的拉取请求，则会出现以下场景：

                       branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /             \
O---O---O---O---------------X
                            ^
                          master

其中 X 现在是合并提交。此后，在没有其他更改或操作的情况下，如果您重新访问 B 的拉取请求，它现在应该（再次）显示 B 和 master 之间的差异，但现在它只包括提交 5-8。

相反，如果您首先完成了 B 的拉取请求，那么您最终会得到以下结果：

                       branch-A       branch-B
                          v               v
              1---2---3---4---5---6---7---8
             /                             \
O---O---O---O-------------------------------Y
                                            ^
                                          master

如果您现在重新访问 A 的拉取请求，根据工具的不同，您可能会看到一个空的差异，或者拉取请求可以被标记为已完成（我似乎记得 Bitbucket for Enterprise 使用这种方法），因为 A 中的所有更改都已完成已经合并成功了。

总结一下：

TL;DR：你的 B 分支并没有真正受到影响，但是它和 master 之间的差异最初也将包括 A 的所有更改，但是在完成 A 的 PR 后，它只会显示 B 和 master 之间的差异，而不再显示显示 A 的更改，因为它们已经被合并。因此，你关于“我的看法”的段落是正确的。

Answer 2

首先要了解的是，拉取请求根本不是 Git 功能。它们是某些 Git 托管站点所做的事情，并且以不同的方式进行。

让我们将我们的考虑范围限制在 GitHub 上。GitHub 以非常方便且连贯的方式处理这种情况。

出于示例目的，假设您有一个分支branchA，并将其作为拉取请求提交到 GitHub，以便合并到main. branchB然后你在末端创建一个新分支branchA并在那里继续开发。这种情况在我身上经常发生，所以我对其运作方式有非常深刻的经验。

有两种可能的理想后续结果：

理想路径1

第一个可能发生的理想情况是，当您仍在处理 时branchB， 的 PRbranchA被接受并合并。然后你只需重新定位branchB到main，如下所示：

git rebase --onto main branchA branchB

这个咒语将提交从偏离的branchB地方撕下来，并将它们附加到 的末尾。您继续工作，直到准备好提交 PR，然后将其合并到. 由于现在直接关闭，PR 将仅包含您在 上所做的提交，这正是您想要的。branchBbranchAmainmainbranchBmainbranchB

请注意，即使添加了更多提交branchA作为其接受的一部分，这也能正常工作。

理想路径2

现在，假设您在PR 尚未被接受branchB时完成了工作。branchA没问题; 继续将 PR 提交branchB到 GitHub，但是当您这样做时，当您在 GitHub Web 界面中构建新的 PR 时，告诉 GitHub 您想要合并branchB到branchA（而不是合并到main）。通过这样做，会发生两件奇妙的事情：

• 的 PRbranchB仅包含您在 上所做的提交branchB，这正是您想要的。

• 如果branchAPR 现在被接受并合并，GitHub会神奇地更改branchBPR，以便它现在要求合并到main！此外，PR仍然只包含您所做的提交branchB！

  即使作为branchA接受的一部分获得了更多的提交，这也可以很好地工作。然而，在这种情况下，在branchAPR 被接受并合并后，您可能想要合并main（branchB“反向合并”）只是为了获取（并且可能协调）最新的更改。