What happens when branched branch gets merged

Question

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

Answer 1

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:

• A pull request for A to master will show the difference between A and master, which is effectively commits 1-4
• A pull request for B to master will show the difference between B and master, which is effectively commits 1-8, and thus includes all changes from A, that has not yet been merged into master

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.

Answer 2

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:

Ideal path 1

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.

Ideal path 2

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.

Answer 3

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.

Answer 4

Based on Lasse's answer, if changes are merged into A after B is created, and then A is merged into B again, before A is merged into master, then everything will work as expected and shown in his answer. Is this correct?

Not exactly: no change is "merged into A".

A is pushed for PR, meaning to request changes from A to be merged to master.

What Lasse V. Karlsen's answer suggests is B is not affected by that.

If B were to be pushed for its own PR (request to merge B changes to master), you would see changes from A and B initially.

But once A has been merged to master, the PR for B would be automatically updated, and would reflect only B changes (to be merged to master), and no longer A changes (already merged to master, since its own PR has been completed).