我有一个问题,我在Git Pro的书中找不到答案。
假设我从master
创建了branchA
,做了一些修改,提交并推送了pull请求。我很确定这个分支在某个时候会合并到origin/master
,但是我想在branchA
之外创建branchB
,以便根据提交的更改进行进一步的开发。
问题是当branchA
被合并时,branchB
会发生什么?
我的看法是,如果pull request approver合并了branchA
,那么我的branchB
pull request将已经包含来自branchA
的提交,并且diff将有效地只显示branchA
和branchB
之间的更改
但是,如果尚未合并,则branchB
的pull请求将显示来自两个分支的更改,并且由批准者合并branchA
然后branchB
或仅branchB
。
请纠正我的推理
4条答案
按热度按时间gwbalxhn1#
你遇到了这种情况:
然后你做了这个:
要总结当前状态,请执行以下操作:
如果你现在决定完成A的pull请求,你会遇到这样的场景:
其中X现在是合并提交。在此之后,没有其他更改或操作,如果您重新访问B的pull请求,它现在应该(再次,仍然)显示B和master之间的差异,但现在它只包括提交5-8。
如果你先完成了B的pull request,你会得到这样的结果:
如果你现在重新访问A的拉取请求,根据工具的不同,你要么会看到一个空的diff,要么拉取请求可以被标记为已完成(我似乎记得Bitbucket for Enterprise使用这种方法),因为A中的所有更改都已经成功合并。
总结一下:
TL;DR:您的B分支实际上没有受到影响,但它和master之间的差异最初也会包括来自A的所有更改,但在完成A的PR后,它只会显示B和master之间的差异,而不再显示来自A的更改,因为它们已经合并。你的“我的看法”这段话是正确的。
uklbhaso2#
首先要理解的是,pull requests根本不是Git的功能。它们是某些Git托管网站所做的事情,并且它们以不同的方式做到这一点。
让我们将我们的考虑限制在GitHub上。GitHub以一种非常方便和连贯的方式处理这种情况。
为了示例的目的,假设你有一个分支
branchA
,你将它作为一个pull request提交给GitHub,以便合并到main
中。然后在branchA
的末尾创建一个新的分支branchB
,并在那里继续开发。这种情况经常发生在我身上,所以我对它的工作原理有很深的经验。有两种可能的理想结果:
理想路径1
可能发生的第一件理想的事情是,当您仍在处理
branchB
时,branchA
的PR被接受并合并。然后,您只需将branchB
重定基到main
,如下所示:该咒语将
branchB
提交从branchB
与branchA
的分歧点剥离,并将它们附加到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
(“反向合并”)中,以获取(或者协调)最新的更改。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。
ejk8hzay4#
根据Lasse的回答,如果在创建B之后将更改合并到A中,然后在A合并到
master
之前再次将A合并到B中,那么一切都将按预期工作,并在他的回答中显示。是这样吗?不完全是没有变化被“合并到A中”。
A被推送为PR,这意味着请求将 * A的更改 * 合并 * 为 *
master
。Lasse V. Karlsen的answer表明B不受此影响。
如果B被推送到它自己的PR(请求将B的更改合并到
master
),您最初会看到来自A * 和 * B的更改。但是一旦A被合并到
master
,B的PR将自动更新,并且将仅反映B的更改(将被合并到master
),而不再是A的更改(* 已经 * 合并到master
,因为它自己的PR已经完成)。