分支合并后会发生什么？

Question

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

假设我从master创建了branchA，进行了一些更改，提交并推送以进行拉取请求。我很确定这个分支最终会合并到origin/master，但我想创建一个基于提交更改的branchA的branchB，以便进行进一步开发。

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

我的理解是如果拉取请求批准者合并branchA，那么我的branchB拉取请求将已经包含来自branchA的提交，差异将有效地只显示branchA和branchB之间的更改。

但是，如果尚未合并，则branchB的拉取请求将显示两个分支的更改，由批准者决定是否同时合并branchA和branchB或仅合并branchB。

请纠正我的理解。

- xwhyz

---

你的推理是正确的。回答你的问题，当branchA被合并时，branchB不会发生任何变化，只有差异会改变为master。 - Tim Biegeleisen

或者仅合并分支B，如果在分支A之前合并，则会有效地合并分支A的更改。 - Lasse V. Karlsen

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的拉动请求合并到主分支，将显示A和主分支之间的差异，即提交1-4
• 将B的拉动请求合并到主分支，将显示B和主分支之间的差异，即提交1-8，因此包括所有来自A的更改，尚未合并到主分支

如果您现在决定完成对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分支实际上没有受影响，但它和主分支之间的差异最初将包括来自A的所有更改，但是在完成A的PR之后，它将仅显示B和主分支之间的差异，并且不再显示A的更改，因为它们已经被合并。关于“我的看法”的段落是完全正确的。

- Lasse V. Karlsen

Answer 2

首先要理解的是，拉取请求并不是 Git 的特性。它们是某些 Git 托管站点所做的事情，而且它们以不同的方式进行。

让我们把考虑范围限定在 GitHub 上。GitHub 以非常方便和一致的方式处理这种情况。

以本例为例，假设您有一个名为 branchA 的分支，并将其提交到 GitHub 作为一个拉取请求，以合并到 main 中。然后，您新建一个基于 branchA 结尾的新分支 branchB 并继续在那里开发。这经常发生在我身上，所以我对它的工作方式有相当深的经验。

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

理想路径1

第一件可能发生的理想事情是，在您仍在处理 branchB 的同时，branchA 的 PR 被接受并合并了。然后，您只需将 branchB 变基到 main 上，就像这样：

git rebase --onto main branchA branchB

这个咒语将 branchB 分支从其与 branchA 分开的点处分离出来，并将它们附加到了 main 的末尾。您可以继续工作，直到准备好提交 PR 时，将其提交以合并到 main 中。由于现在 branchB 直接来自于 main，因此 PR 只包含您在 branchB 上进行的更改，这正是您想要的。

请注意，即使在接受过程中向 branchA 添加了更多提交内容，这种方法也能正常工作。

理想路径 2

现在假设你完成了branchB的工作，而branchA的PR还没有被接受。没问题，继续将branchB的PR提交到GitHub，但是当你在GitHub网页界面构建新的PR时，告诉GitHub你想将branchB合并到branchA（而不是合并到main）。这样做会发生两件美妙的事情：

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

• 如果现在接受并合并了 branchA 的 PR，则 GitHub 会自动更改 branchB 的 PR，以便它现在要求合并到 main！此外，PR 仍然仅由您在 branchB 上所做的提交组成！

  即使 branchA 在其被接受时获得了更多提交，这也完全可行。在这种情况下，但是，在接受并合并 branchA PR 后，您可能需要将 main 合并到 branchB（“反向合并”）中，以获取（并可能协调）最新更改。

- matt

Answer 3

我的理解是，如果拉取请求的批准者合并了branchA，那么我的branchB拉取请求将已经包含来自branchA的提交，差异将有效地显示branchA和branchB之间的更改。

这取决于您如何设置BranchB的拉取请求。如果您选择将其合并到master中，并且BranchA尚未合并，则会看到所有更改。但是，您还可以创建拉取请求，说将BranchB合并到BranchA中，然后您只能看到从BranchB到BranchA的更改。

您始终可以更改要将分支合并到哪个分支。因此，首先假设您设置了拉取请求以将BranchB合并到BranchA中，以仅查看该差异。如果BranchA被合并到主分支，则可以将BranchB重新基于或将主分支合并到BranchB中。

- caramba

Answer 4

根据Lasse的回答，如果在创建B之后将更改合并到A中，并且然后再将A合并到B中，在将A合并到主分支(master)之前，那么一切都会按照他的回答所示正常工作。这是正确的吗？

不完全正确：没有任何更改“合并到A”中。

A被推送用于PR，意味着从A请求更改以将其合并到主分支（master）中。

Lasse V. Karlsen的答案建议B不受此影响。

如果B要求进行自己的PR（请求将B更改合并到master中），则最初会看到来自A和B的更改。

但是一旦A已经合并到master中，B的PR将自动更新，并且将仅反映B的更改（将要合并到master中），而不再是A的更改（已经合并到master中，因为它自己的PR已经完成）。

- VonC