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

8yoxcaq7  于 2023-05-05  发布在  Git
关注(0)|答案(4)|浏览(209)

我有一个问题,我在Git Pro的书中找不到答案。
假设我从master创建了branchA,做了一些修改,提交并推送了pull请求。我很确定这个分支在某个时候会合并到origin/master,但是我想在branchA之外创建branchB,以便根据提交的更改进行进一步的开发。
问题是当branchA被合并时,branchB会发生什么?
我的看法是,如果pull request approver合并了branchA,那么我的branchB pull request将已经包含来自branchA的提交,并且diff将有效地只显示branchAbranchB之间的更改
但是,如果尚未合并,则branchB的pull请求将显示来自两个分支的更改,并且由批准者合并branchA然后branchB或仅branchB
请纠正我的推理

gwbalxhn

gwbalxhn1#

你遇到了这种情况:

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的pull请求将显示A和master之间的差异,这实际上是提交1-4
  • B到master的pull请求将显示B和master之间的差异,这实际上是提交1-8,因此包括来自A的尚未合并到master中的所有更改

如果你现在决定完成A的pull请求,你会遇到这样的场景:

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

其中X现在是合并提交。在此之后,没有其他更改或操作,如果您重新访问B的pull请求,它现在应该(再次,仍然)显示B和master之间的差异,但现在它只包括提交5-8。
如果你先完成了B的pull request,你会得到这样的结果:

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

如果你现在重新访问A的拉取请求,根据工具的不同,你要么会看到一个空的diff,要么拉取请求可以被标记为已完成(我似乎记得Bitbucket for Enterprise使用这种方法),因为A中的所有更改都已经成功合并。
总结一下:

TL;DR:您的B分支实际上没有受到影响,但它和master之间的差异最初也会包括来自A的所有更改,但在完成A的PR后,它只会显示B和master之间的差异,而不再显示来自A的更改,因为它们已经合并。你的“我的看法”这段话是正确的。

uklbhaso

uklbhaso2#

首先要理解的是,pull requests根本不是Git的功能。它们是某些Git托管网站所做的事情,并且它们以不同的方式做到这一点。
让我们将我们的考虑限制在GitHub上。GitHub以一种非常方便和连贯的方式处理这种情况。
为了示例的目的,假设你有一个分支branchA,你将它作为一个pull request提交给GitHub,以便合并到main中。然后在branchA的末尾创建一个新的分支branchB,并在那里继续开发。这种情况经常发生在我身上,所以我对它的工作原理有很深的经验。
有两种可能的理想结果:

理想路径1

可能发生的第一件理想的事情是,当您仍在处理branchB时,branchA的PR被接受并合并。然后,您只需将branchB重定基到main,如下所示:

git rebase --onto main branchA branchB

该咒语将branchB提交从branchBbranchA的分歧点剥离,并将它们附加到main的末尾。您可以继续工作,直到准备好提交PR,然后将其提交以合并到main中。由于branchB现在直接来自main,PR将只包含您在branchB上所做的提交,这正是您想要的。
请注意,即使在接受branchA * 时添加了更多提交,它也能正常工作。

理想路径2

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

  • branchB的PR只包含您在branchB上所做的提交,这正是您想要的。
  • 如果branchA PR现在被接受并合并,GitHub * 会神奇地更改branchB PR*,以便它现在要求合并到main!此外,PR still 只包含您在branchB上所做的提交!

即使branchA作为接受的一部分获得了更多的提交,它也能正常工作。但是,在这种情况下,在branchA PR被接受并合并之后,您可能希望将main合并到branchB(“反向合并”)中,以获取(或者协调)最新的更改。

sczxawaw

sczxawaw3#

我的看法是,如果pull request approver合并了branchA,那么我的branchB pull request就已经包含了branchA的提交,而diff实际上只会显示branchA和branchB之间的更改
这取决于您如何设置BranchB的合并请求。如果您选择将其合并到master中,而BranchA尚未合并,则您将看到所有更改。但是你也可以创建合并请求,说将BranchB合并到BranchA,然后你只看到从BranchB到BranchA的更改。
您始终可以更改分支将合并到哪个分支。因此,假设您首先设置Pull Request,将BranchB合并到BranchA中,只查看差异。如果BranchA被合并到master,你可以重定BranchB的基,或者将master合并到BranchB。

ejk8hzay

ejk8hzay4#

根据Lasse的回答,如果在创建B之后将更改合并到A中,然后在A合并到master之前再次将A合并到B中,那么一切都将按预期工作,并在他的回答中显示。是这样吗?
不完全是没有变化被“合并到A中”。
A被推送为PR,这意味着请求将 * A的更改 * 合并 * 为 * master
Lasse V. Karlsenanswer表明B不受此影响。
如果B被推送到它自己的PR(请求将B的更改合并到master),您最初会看到来自A * 和 * B的更改。
但是一旦A被合并到master,B的PR将自动更新,并且将仅反映B的更改(将被合并到master),而不再是A的更改(* 已经 * 合并到master,因为它自己的PR已经完成)。

相关问题