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

Question

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?

score 147 · Accepted Answer · edited Dec 25 '18 at 01:59

147

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.

screenshot

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.

edited Dec 25 '18 at 01:59

tim-phillips

997
1
11
22

answered Aug 16 '16 at 23:30

maliayas

2,674
1
18
17

This feature doesn't seem to exist anymore (as of 2018-02-15), does it? In a recent pull request the target branch is displayed in the same blue font on light blue background as the source repository/branch and not a button anymore. – cgogolin Feb 15 '18 at 14:01
18

Ah! It does! One first needs to click on "Edit" (which is not obvious from the above screenshot). I overlooked this. Sorry. – cgogolin Feb 15 '18 at 14:02
@cgogolin Thanks for pointing that out – I was confused too, until I read your comment and clicked on the Edit button. – mhucka May 12 '18 at 23:39
[Github warns](https://help.github.com/en/articles/changing-the-base-branch-of-a-pull-request) that "When you change the base branch of your pull request, some commits may be removed from the timeline." and "Some commits from the old base branch may be removed from the timeline." Any idea what this means? – Matthias Fripp Jun 14 '19 at 21:40
But you still can't create a _new_ branch to merge into. – GaryO Aug 26 '19 at 20:59
Does this still work? When I open the drop-down for branches in either repo, I get a search field but no matched branches whatsoever and hitting enter doesn't select it either even when completely and correctly spelled, so I'm very confused. – ecv Apr 22 '22 at 01:22
1

What the warning about "commits from the old base branch may be removed from the timeline" means is that the timeline (the list of which commits are included in that PR) may change if you changes branches (in the case where some of the commits in the PR already existed in the newly selected branch) – Jason Kohles Nov 07 '22 at 15:13

Daniel Pittman · Answer 2 · 2012-02-04T20:17:58.273

55

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:

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

edited Feb 04 '12 at 20:17

answered Feb 03 '12 at 22:14

Daniel Pittman

16,733
4
41
34

1

If I manually merge and push, will Github realise that the pull request has been effectively completed? Any pointers on how to merge from a remote separate repo (the fork)? – eoinoc Feb 04 '12 at 20:01
3

I am not sure, but not directly - because the change didn't merge into the target branch, so the pull request is not completed as defined. You need to manually close it. As to the pointers, see the edited comment. – Daniel Pittman Feb 04 '12 at 20:16
I'd recommend using `git merge --no-ff ...` as @GuillermoMansilla mentions in his answer. – jjmontes May 31 '16 at 16:07
5

"Once they issue it you can't change it" - No longer the case as of August 2016! See @maliayas 's answer below: http://stackoverflow.com/a/38985999/12484 – Jon Schneider Oct 11 '16 at 15:18
2

I followed this procedure today (Mar 3 2017). I downloaded pull request into another branch and made some additional fixes to it, then merged to master. Once commits from the pull request ended up in master, GitHub automatically closed the pull request. – Ivan Krivyakov Mar 05 '17 at 01:46

score 16 · Answer 3 · edited Aug 02 '16 at 17:36

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.

Deckard · Answer 4 · 2022-02-14T16:41:03.020

10

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!

edited Feb 14 '22 at 16:41

answered Sep 11 '14 at 20:37

Deckard

2,384
1
19
35

1

Does this work if they have changed their repository? How does one ensure that it's "the same commits?" – interestedparty333 Oct 09 '14 at 23:34
@ragerdl - If you're developing using a 'feature-per-branch' model, then you can create a PR with a branch against an upstream branch, and it should contain the same commits. – geerlingguy Apr 01 '15 at 14:24
2

The only way to do it directly on GitHub, without access to a local repo. – kopischke Dec 17 '15 at 16:42
Underrated solution. Thanks. – Victor Eke Jan 24 '23 at 23:39

score 8 · Answer 5 · edited Jun 20 '20 at 09:12

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.

enter image description here

score 7 · Answer 6 · edited Aug 02 '16 at 17:40

7

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.

enter image description here

edited Aug 02 '16 at 17:40

the Tin Man

158,662
42
215
303

answered Jul 09 '15 at 07:42

abbood

23,101
16
132
246

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

6 Answers6

Linked