Reputation: 1514
I have a question for which I couldn't find an answer in Git Pro book.
Suppose I created branchA
off master
, did some changes, commited and pushed for pull request.
I'm pretty sure that this branch will get merged to origin/master
at some point but I want to create branchB
off branchA
for further development based on submitted change.
Question is what happens with branchB
when branchA
will get merged?
My take is that if pull request approver merges branchA
then my branchB
pull request will already contain commits from branchA
and diff will effectively show only changes between branchA
and branchB
However if it's not yet merged, pull request for branchB
will show changes from both branches and it's up to approver to either merge branchA
and then branchB
or only branchB
.
Please correct my reasoning
Upvotes: 18
Views: 6313
Reputation: 535988
The first thing to understand is that pull requests are not at all a Git feature. They are something that certain Git hosting sites do, and they do it in different ways.
Let's confine our considerations to GitHub. GitHub handles this situation in a very convenient and coherent way.
For purposes of the example, let's say you have a branch branchA
and you submit it to GitHub as a pull request to be merged into main
. You then make a new branch branchB
off the end of branchA
and you continue development there. This happens to me a lot, so I have pretty deep experience of how it works.
There are two possible ideal subsequent outcomes:
The first ideal thing that might happen is that while you are still working on branchB
, the PR for branchA
is accepted and merged. Then you simply rebase branchB
onto main
, like this:
git rebase --onto main branchA branchB
That incantation rips the branchB
commits off the point where branchB
diverged from branchA
and tacks them on to the end of main
. You continue working until you are ready to submit the PR, and you submit it to be merged into main
. Since branchB
now comes directly off main
, the PR will consist only of the commits that you've made on branchB
, which is just what you want.
Observe that this works just fine even if more commits were added to branchA
as part of its acceptance.
Now let's say that, instead, you finish your branchB
work while the branchA
PR has not yet been accepted. No problem; go ahead and submit the PR for branchB
to GitHub, but when you do, as you construct the new PR in the GitHub web interface, tell GitHub that you want to merge branchB
into branchA
(not into main
). By doing that, two wonderful things happen:
The PR for branchB
consists only of the commits you made on branchB
, which is just what you want.
If the branchA
PR is now accepted and merged, GitHub magically changes the branchB
PR so that it is now asking to merge into main
! Moreover, the PR still consists only of the commits you made on branchB
!
That, too, works just fine even if branchA
acquired some more commits as part of its acceptance. In that case, however, after branchA
PR is accepted and merged, you might want to merge main
into branchB
("reverse merge") just to pick up (and perhaps reconcile) the latest changes.
Upvotes: 6
Reputation: 391664
You had this situation:
branch-A
v
1---2---3---4
/
O---O---O---O
^
master
Then you did this:
branch-A branch-B
v v
1---2---3---4---5---6---7---8
/
O---O---O---O
^
master
To summarize the current state:
If you now decide to complete the pull request for A, you have this scenario:
branch-A branch-B
v v
1---2---3---4---5---6---7---8
/ \
O---O---O---O---------------X
^
master
Where X is now the merge commit. After this, with no other changes or operations, if you revisit the pull request for B it should now (again, still) show the difference between B and master, but now it only includes commits 5-8.
If instead you had completed pull request for B first, you had ended up with this:
branch-A branch-B
v v
1---2---3---4---5---6---7---8
/ \
O---O---O---O-------------------------------Y
^
master
If you now revisit the pull request for A, depending on the tool you would either see an empty diff, or the pull request can be marked as completed (I seem to recall Bitbucket for Enterprise uses this approach), as all changes in A have already been merged successfully.
So to summarize:
TL;DR: Your B-branch is not really affected, but the diff between it and master will initially include all changes from A as well, but after completing PR for A, it will only show diff between B and master, and no longer show the changes from A as they have already been merged. Your paragraph about "My take" is thus spot on.
Upvotes: 21
Reputation: 22490
My take is that if pull request approver merges branchA then my branchB pull request will already contain commits from branchA and diff will effectively show only changes between branchA and branchB
It depends how you setup the Pull Request for BranchB. If you select to merge it into master
and BranchA is not yet merged you will see all changes. But you can also create the Pull Request saying merge BranchB into BranchA then you only see the changes from BranchB to BranchA.
You can always change to which branch a branch will be merged. So assume first you setup Pull Request to merge BranchB into BranchA to see only that diff. If BranchA gets merged to master you can either rebase BranchB or merge master into BranchB.
Upvotes: 0