A feature branch on top of another feature branch (dealing with PRs)

Question

As shown in the following image, I have two different branches with their corresponding PRs (PR1 and PR2). The top arrow is the develop branch.

PR2 is build on top of PR1. PR1 is build on top of develop. Keep in mind that I also compared PR2 to PR1 in the Github UI.

Now, at some point in time as shown below, I needed some changes from the Bout branch so I merged it into my PR2 from develop. Then, when I came back and looked at the Github UI for PR2, I saw a very long list of contributors (on the right side of the page). That was not right to me!

So, I changed the comparison (on top of the Github UI) dropdown; from PR2 versus PR1 to PR2 versus develop. With that changes, the number of contributors got corrected to what I had in mind (myself and contributors of Bout). After doing this, I see that ALL COMMITS from PR1 are in my PR2 (listed in the Github UI in the chronological order).

Now, my questions are:

1. I want PR1 to land (into develop), then start landing PR2. Is that possible?
2. If I land PR2, what will happen to Bout? If Bout is landed before PR2, will I get conflicts? How can I resolve it?
3. What did I do wrong in the first place when I merged Bout into PR2? Was I supposed to move the PR1 and PR2 move forward to the base commit of Bout, and then start merging Bout?
4. Should I always compare against develop even if I create a branch on top of another one?
5. My last and important question: What should I do as my next steps to have a clean state? "Clean state" means landing PR1 and PR2 without any big conflicts (with each other and with Bout); BTW, Bout is not mine and it will land separately by its owner.

I am worried about the fact that when I land PR1, I am messing PR2's state. And also, PR2 will mess up Bout?!?

Really appreciate your help!

I am aware of the following questions on SO, but none was helpful to me:

https://stackoverflow.com/questions/14893399/rebase-feature-branch-onto-another-feature-branch

In GitHub flow, is it OK to base feature branch on another feature branch?

Answer 1

In my answer, I am assuming that merges are done with a merge-commit (or a fast-forward merge without any rebasing). If that is not true, then my answer does not apply and you are in for a lot more pain from merge conflicts.

1. I want PR1 to land (into develop), then start landing PR2. Is that possible?

Yes, that is definitely possible. And it is actually the preferred way to merge/land those branches.

2. If I land PR2, what will happen to Bout? If Bout is landed before PR2, will I get conflicts? How can I resolve it?

If you merge/land PR2 first, then you are effectively incorporating the state of Bout that you included in PR2 already into develop. A subsequent merge/landing of Bout will then only include the changes made to Bout after your merge to PR2.

If Bout gets landed/merged first to develop, you might get some conflicts from changed made to Bout after your merge, but otherwise you should be fine.

3. What did I do wrong in the first place when I merged Bout into PR2? Was I supposed to move the PR1 and PR2 move forward to the base commit of Bout, and then start merging Bout?

When you merged Bout into PR2 and compared that result to PR1, GitHub was showing you all the differences made to develop, Bout and PR2 that were not present on PR1. That was probably more than you were expecting.

4. Should I always compare against develop even if I create a branch on top of another one?

My advise would be to compare against the branch that gives you the clearest view of the changes you have made to the current branch. If you have not merged any other branches into your work, that would be the branch you branched off from. If you have made merges (and created a complicated graph of your branches that way), compare to the most common ancestor of all branches, commonly develop.

5. My last and important question: What should I do as my next steps to have a clean state? "Clean state" means landing PR1 and PR2 without any big conflicts (with each other and with Bout); BTW, Bout is not mine and it will land separately by its owner.

You will get the cleanest state if you merge/land PR1 first. Then wait for Bout to be merged/landed and finally merge/land PR2.

If you can't wait for Bout to be merged, discuss the situation with its owner, because merging PR2 first will cause Bout to be on develop as well.

Answer 2

You seem to be describing a Sprint planning problem here, where arranging for straightforward merges becomes difficult due to too many cooks in the kitchen.

PR1 was small, and it has not yet landed on develop.

PR2 incorporates both PR1 and Bout, and it will be a "big" PR.

Continue to develop PR2. Pay attention to the schedule for Bout to merged down. After that happens, PR2 will have a "small" amount of diffs and authors. So approving the merge should be straightforward.

---

What can we learn from this, going forward? There are alternate sprint planning scenarios:

1. The PR2 devs could have remained idle (that is, working on other stories) until Bout merged down.
2. The PR2 devs could have better coordinated with the Bout development team to minimize merge issues.
3. The PR2 devs should perhaps become part of the Bout development team, at least for a little while.

---

Alternatively, perhaps just a small subset of the Bout branch was really necessary for forward progress.

Go to the trouble of capturing the minimal subset of changes. Use them during PR2 development. Verify that they merge cleanly.

Presumably PR2's new features are in new files that won't cause any merge conflicts.