Merge pull request to a different branch than default, in Github

A pull request comes into my repo hosted on Github. By default it is merged into the master branch.

Is there any way for me to change which branch the changes would be merged into?

As of 15.08.2016 GitHub allows changing the target branch of a pull request via the GUI. Click Edit next to the title, then select the branch from the dropdown.

> You can now change the base branch of an open pull request. After you’ve created a pull request, you can modify the base branch so that the changes in the pull request are compared against a different branch. By changing the base branch of your original pull request rather than opening a new one with the correct base branch, you’ll be able to keep valuable work and discussion.

The submitter can change that when they issue the pull request, but once they issue it you can't change it.

On the other hand, you can manually merge their branch and push, which I semi-regularly do for mistargetted pull requests.

You may find the hub gem helpful in working with the components of the pull request.

That gem wraps up the manual process, which is:

1. Add a remote for the fork to your local checkout.
2. Fetch that remote.
3. git checkout ${target_branch} && git merge ${remote}/${branch}
4. git push origin ...

An alternative to using the hub gem mentioned by other answers is to use the command line to merge locally pull requests, which allows you to do:

$ git fetch origin
$ git checkout *target_branch*
$ git merge pr/XXX
$ git push origin *target_branch*

---

The commands above only work directly if you first add the following line to your .git/config file:

fetch = +refs/pull/*/head:refs/remotes/symbolic_name_origin_or_upstream/pr/*

What that does is allow you to download ALL pull requests. Since that may not be desired for huge repos, GitHub modified the instructions to feature the git fetch origin pull/ID/head:BRANCHNAME syntax, which avoids modification of the configuration file and only downloads that single pull request.

Although you cannot change the existing pull request as it is not yours, you can easily create a new one if the related source repository still exists - yes, even if it is someone else's.

Go to the repository of the submitter then create a new pull request in his/her repository using the same commits but make sure you set the right target branch correctly.

Then go back to your own repository and accept the new pull request. Voila!

There is nothing wrong with Daniel Pittman's solution, however I would treat those merges as "no fast forward", that is, changing step number 3 for:

git checkout ${target_branch} && git merge --no-ff ${remote}/${branch}

By using --no-ff, the history will be easier to read. It will clearly say that $n commits came from $branch, and it will also make your life easier if you need to revert something done in that branch.

To also answer eoinoc's question and give an additional tip:

After doing the merge, your git cli will prompt you to write a message, generally a generic message will show up saying something like

>Merge remote-tracking branch 'user/their-branch' into your-branch

Make sure to edit that message and include a reference to the pull request number. That is: (Assuming the pull request number is 123) >Merge remote-tracking branch 'user/their-branch' into your-branch > >refs #123 solving whatever...

So next time you visit your github issues/pull-requests page and check that particular pull request, you will see your message with a link to commit where you did the merge.

Here is a screenshot of what I mean.

To do that go to your repository's home page, click on branches, and change the default branch from master into something else, in my case "dev".

After that, whenever someone creates a pull request the merge button will automatically merge the request into "dev" rather than master.