How do I handle parallel pull requests for derived branches?

Question

My team wants me to create a separate pull request (with Bitbucket) for each logical change in a project so that it can be reviewed and approved easily.

I need to implement features A, B and C.

I created branch A, implemented the first change and created a pull request for A-->master. Now while I am waiting for review and approval I want to work on the next feature. I created a branch B derived from A.

master
      \
       A
        \
         B

Now I also finished implementing B and want to create another pull request for my team to review. If I do so (B-->master) it shows me both commits from A and B (which makes sense of course), but I don't want my team to review A again.

I know that I could make the second pull request B-->A but what will happen to this pull request if A is merged into master and deleted afterwards before B was merged into A?

How can I have parallel pull requests that contain the changes for A and B but which are disjoint?

Answer 1

Make a branch for each feature. These are called feature branches. If you need to, branch off another branch. git checkout feature/1; git branch feature/2.

          D - E - F [feature/3]
         /
A - B - C [master]
         \
          G - H [feature/1]
               \
                I - J [feature/2]

You can submit feature/2 and feature/1 at the same time, so long as you make it clear that feature/2 depends on feature/1.

I know that I could make the second pull request B-->A but what will happen to this pull request if A is merged into master and deleted afterwards before B was merged into A?

If feature/1 is revised and not yet merged, you should rebase feature/2 on top of it with git checkout feature/2; git rebase feature/1. That would look like this, K and L are the new revisions.

          D - E - F [feature/3]
         /
A - B - C [master]
         \
          G - H - K - L [feature/1]
               \
                I - J [feature/2]

Then after git checkout feature/2; git rebase feature/1 you'd have this:

          D - E - F [feature/3]
         /
A - B - C [master]
         \
          G - H - K - L [feature/1]
               \       \
                I - J   I1 - J1 [feature/2]

Then git push --force on feature/2. Note that the original changes are still there on your local repository after a rebase. They'll eventually be garbage collected, but meanwhile if you made a mistake you can get them back by examining git reflog.

Same procedure after feature/1 has been merged and deleted (btw, you'll still have your local branch that you'll have to delete). Deleting a branch only deletes the label, the branch is still there (unless they "merge" by rebasing or squashing). You'll have this.

          D - E - F [feature/3]
         /
A - B - C ------------- M [master]
         \             /
          G - H - K - L
                       \
                        I1 - J1 [feature/2]

You should rebase feature/2 onto master with git rebase master.

          D - E - F [feature/3]
         /
A - B - C ------------- M [master]
         \             / \
          G - H - K - L   I2 - J2 [feature/2]

And then git push --force.

Similarly, if feature/3 is still under review you should rebase feature/3 onto master to ensure it still works and to make the integrator's job easier.

---

If all this seems a little complicated, then submit feature/1 and wait until after it's accepted and merged to submit feature/2. You should still do that last bit, rebase feature/2 onto master.

Answer 2

So, you have a master branch.

• Create a new branch from master named A.
• Create a pull request for branch A
• Create another branch, B from branch A.

Now, since B was created from A, it will have the commits from A as well. And even if A gets merged into the master branch and the pull request for branch A will close, the branch A still remains.

• So take a master rebase (git rebase master) on branch A
• And then take a rebase on branch B from A
• Finally take master rebase on branch B.