How to submit multiple pull-requests in GitHub when they may conflict slightly

Question

I am submitting two independent new features to a project as pull-requests. Each feature is in a topic branch, each branching from the tip of master.

          /-- feature1
master ---
          \-- feature2

The problem is that while either branch can be cleanly merged into master by itself, when the second branch is merged it will create conflicts. This isn't because the features depend on each other, they just happen to touch the same code.

A trivial example: if the original file was a comma-separated list, and each commit wanted to add one new item to it, it may look like this:

master:
a,
b,
c

feature1:

- c
+ c,
+ d

feature2:

- c
+ c,
+ e

At the end of the day, if both pull-requests are accepted, both d and e should eventually be added to the list, in any order (since the features are entirely separate, so they don't depend on each other). However, if you tried to pull them both in you'd get a conflict.

What's the best way to deal with this? Should feature2 be based off of the end of feature1, and then they should be merged in the correct order into master?

master ---
          \--- feature1
              \------ feature2

If I did that, would the pull-request for feature2 show just the feature2 commits, or will it show all the feature1+feature2 commits?

Or should I just rebase feature2 after feature1 is merged into master?

Answer 1

Since neither feature build off the other, you should just branch both off of master as you originally would have. This even though they touch a common file (insignificantly).

Then rebase the second pull request (feature2) after the first one (feature1) is merged with the original master (or rebase feature1 if feature2 is merged first).

git fetch upstream
git rebase upstream/master feature2

Here we grab the commits from upstream (original source you've forked from) and then rebase our local feature branch with its commits.

Then fix up any merge conflicts you may encounter and push that commit back up to your fork. The pull request for feature2 will update, now including a commit that fixes up the possible merge conflict and make merging back to the original that much cleaner/easier.

Or the original repository will just grab both of your pull request branches and merge them in themselves, fixing any conflicts that may come up.

Answer 2

Should feature2 be based off of the end of feature1, and then they should be merged in the correct order into master?

8 years later (2013-2021), note that GitHub helps answering that question with the notion of Merge Queue:

Pull Request Merge Queue Limited Beta (Oct. 2021)

Why a merge queue?

Maintaining high velocity and keeping your main branch green can be a challenge today. Many repositories try to do this by requiring all pull requests be up to date with the main branch before merging.
This ensures the main branch is never updated to a commit that has not passed all required status checks, but forces developers to update (or rebase) their pull request branches multiple times and then wait for status checks to complete before trying to merge again.

On some projects, status checks can take 30 or more minutes and if another pull request gets merged during this time, the process starts over (for everyone). This can have a significant impact on the overall velocity of the team and make it harder for developers to move onto their next task.

Merge Queue provides the benefits of requiring pull request branches to be up to date before merging, but without requiring developers to go through this process.

How it works

Merge Queue works by validating different combinations of pull requests identified as "ready to merge" in parallel so that pull requests can merge efficiently and without the typical delays that exist between merges today.

Once a pull request has been approved and has passed all required status checks, a user with write access in the repository can queue the pull request to be merged.

The pull request branch does not need to be up to date with the base branch before being queued. The merge queue then creates a temporary branch that includes the pull request and any non-failing pull requests ahead of it in the queue.

This branch is based on the latest version of the base branch and is what the history of the base branch will look like if it passes all required status checks.
Assuming it does pass these checks, the base branch is fast-forwarded and the pull request is marked as merged.

And the GitHub CLI gh comes with (v2.12.0, June 2022):

---

merge queue support for pr merge

Adds merge queue support to the pr merge command.