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

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

Pull request merge queue (public beta) (Feb. 2023)

Today we are announcing the public beta of pull request merge queue for repos on GitHub Enterprise Cloud and open source organizations!

Merge queue helps increase velocity in software delivery by automating pull request merges into your busiest branches.

Before merge queue, developers were often required to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch when merged.
Each update resulted in a fresh round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge.
If another pull request got merged, every developer would have to go through the process again.

Merge queue automates this process by ensuring each pull request queued for merging is built with the pull requests ahead of it in the queue.

If your pull request targets a branch that uses merge queue, instead of merging your pull request directly when it meets the requirements to merge, you will add it to the queue by clicking Merge when ready from the pull request page or from GitHub Mobile.

The queue then creates a temporary branch that contains the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request.
CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.

If a queued pull request has merge conflicts or fails any required status check, it is automatically removed from the queue when it reaches the front, and a notification is sent.
Once the problem is resolved, it can be added back to the queue.

Learn more about merging a pull request with merge queue from the pull request page.
You can also queue your pull request on the go using the beta version of GitHub Mobile from iOS TestFlight or Google Play (Beta)!

Always know where you are in the queue.

The queue details page, which can be accessed from the Branches page or pull request page, shows the pull requests in the queue and status for each, including the required status checks and estimated time to merge.
It also shows how many pull requests have been merged and the trend over the last 30 days.

Depending on your permissions, you can also remove a pull request from the queue or clear the queue from this page.

Merge queue can help improve overall velocity and avoid manual branch updates that impact developer productivity.
Learn more about how to enable merge queue on your busiest branches.

We want to hear from you on how we can improve merge queue! Join the conversation in the merge queue public beta discussion.

---

Pull request merge queue (public beta): API support and recent fixes (Apr. 2023)

As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback> and let you know about some recent fixes and new API support.

See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.

You can now interact with merge queue programmatically using new GraphQL APIs.
Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more.
For example:

Call the enqueuePullRequest mutation to add a pull request to the queue or dequeuePullRequest to remove a pull request.

Use the mergeQueue field on Repository to list its contents or configuration.
Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.

Some of the more noteworthy fixes made since the public beta launch:

• Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
• Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
• Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
• Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)

Interested in merge queue? Learn how to get started.

---

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.

---

Dec. 2023, Eldrick Wega proposes "Enabling GitHub Advanced Security as a required check with a GitHub Merge Queue"

When GitHub Advanced Security’s CodeQL scan runs on a pull request, it runs the analysis (by default this is a job in GitHub Actions called “Analyze”) and then outputs the results of the analysis to GitHub. This output is, by default, called “Code scanning results / CodeQL”.

Doing this, however, within the context of a merge queue will cause this check to be required in the merge queue. However, the output is never uploaded to the merge queue, making it an expected check that is never completed.

The fact that the output of “Code scanning results” is never uploaded could be considered a bug. At the time of writing this, this is being worked on by GitHub, however there are no timelines. This is a workaround until then

Eldrick then describes:

Answer 2

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.