Categories
git

Make the current Git branch a master branch

1952

I have a repository in Git. I made a branch, then did some changes both to the master and to the branch.

Then, tens of commits later, I realized the branch is in much better state than the master, so I want the branch to “become” the master and disregard the changes on master.

I cannot merge it, because I don’t want to keep the changes on master. What should I do?

Extra: In this case, the ‘old’ master has already been push-ed to another repository such as GitHub. How does this change things?

3

  • 3

    Check answers to the very similar question stackoverflow.com/q/2862590/151641

    – mloskot

    Apr 25, 2012 at 23:29

  • 6

    Had a same problem, however I simply removed the master and renamed another branch to master: stackoverflow.com/a/14518201/189673

    – jayarjo

    Jan 25, 2013 at 8:52


  • 12

    @jayarjo you should avoid this if you possibly can because it will rewrite history and cause problems for everyone else when they next try to pull master.

    Sep 19, 2013 at 9:17

2440

The problem with the other two answers is that the new master doesn’t have the old master as an ancestor, so when you push it, everyone else will get messed up. This is what you want to do:

git checkout better_branch
git merge --strategy=ours master    # keep the content of this branch, but record a merge
git checkout master
git merge better_branch             # fast-forward master up to the merge

If you want your history to be a little clearer, I’d recommend adding some information to the merge commit message to make it clear what you’ve done. Change the second line to:

git merge --strategy=ours --no-commit master
git commit          # add information to the template merge message

34

  • 29

    Note about git’s merge “strategies”: --strategy=ours is different from --strategy=recursive -Xours. I.e. “ours” can be a strategy in itself (result will be the current branch no matter what), or passed as an option to the “recursive” strategy (bring in other branch’s changes, and automatically prefer current branch’s changes when there’s a conflict).

    – Kelvin

    Apr 11, 2014 at 20:17


  • 9

    I had to make the second line git merge --strategy=ours master -m "new master" for it to work.

    Jun 4, 2015 at 5:07

  • 7

    @Johsm That’s exactly what the first sentence of my answer is talking about. If you do that, the new master will not have the same history as the old master, which is Very Bad if you want to push/pull. You need to have shared ancestry for that to work correctly; if instead you do what you’re saying, then when you try to push it’ll simply fail unless you force it (because this is Bad and it’s trying to stop you), and if you do force it, then anyone who subsequently pulls will attempt to merge the old master and the new master, which will probably be a train wreck.

    – Cascabel

    Nov 15, 2015 at 16:47

  • 4

    If vi editor during merge appears, type :w (for saving) :q (for exiting from vi)

    Oct 27, 2016 at 9:23

  • 15

    This answer works great. I just wanted to add (for the people who may be new or unsure) that you’ll have to do a git push right after this if you want your code pushed up to remote. You may see a warning like Your branch is ahead of 'origin/master' by 50 commits. This is expected. Just push it! 😀

    Jun 26, 2017 at 18:23

603

+50

Make sure everything is pushed up to your remote repository (GitHub):

git checkout main

Overwrite “main” with “better_branch”:

git reset --hard better_branch

Force the push to your remote repository:

git push -f origin main

8

  • 122

    This is probably the answer most people are looking for. All the other answers with the BS strategy merge do not replace the branch entirely. This made everything just like I wanted, simply overwrite the branch and push force it up.

    – Gubatron

    Jan 3, 2017 at 21:35

  • 45

    although this is indeed what many are looking for, it should be noted that any other local copies of the repo will need to git reset --hard origin/master next time they want to pull, else git will try to merge the changes into their (now) divergent local. The dangers of this are explained more in this answer

    – 7yl4r

    Mar 27, 2017 at 14:56


  • 7

    please also note that you need to be allowed to force push to the repository – e.g in a business environment this won’t work

    Jun 20, 2018 at 14:02

  • 3

    The upside here can also be a downside depending on what people want. If you want to go as far as replacing the history of master with the history of the other branch, this is your answer.

    – b15

    Mar 11, 2020 at 16:03

  • This is the answer I was looking for, since my new branch was from master commit. This makes it easy for any branch from previous master not to have much merge issues.

    Jul 6, 2020 at 1:35

83

Edit: You didn’t say you had pushed to a public repo! That makes a world of difference.

There are two ways, the “dirty” way and the “clean” way. Suppose your branch is named new-master. This is the clean way:

git checkout new-master
git branch -m master old-master
git branch -m new-master master
# And don't do this part.  Just don't.  But if you want to...
# git branch -d --force old-master

This will make the config files change to match the renamed branches.

You can also do it the dirty way, which won’t update the config files. This is kind of what goes on under the hood of the above…

mv -i .git/refs/new-master .git/refs/master
git checkout master

17

  • 2

    Thank you. One more question. I am pushing it to github. What will happen on there, if I do this?

    May 4, 2010 at 5:42

  • 3

    @Karel: It’ll create a bit of a mess for other users; they’ll have to reset their master to the github master. If you want to avoid causing them any trouble, have a look at my answer.

    – Cascabel

    May 4, 2010 at 6:00

  • 6

    @Dietrick Epp: I’m not sure if it’s a good idea to even suggest the dirty way. It’s going to mess up remote tracking, reflogs… can’t think of any reason you’d ever do it.

    – Cascabel

    May 4, 2010 at 6:08

  • 2

    Ah, that’s a good point. You can have it both ways, though: git branch old-master master; git branch -f master new-master. Create the backup branch fresh, then directly move master to new-master. (And sorry for misspelling your name, just noticed that)

    – Cascabel

    May 5, 2010 at 2:43

  • 2

    @FakeName I didn’t conclude there was no reason to do it, just that there’s no reason to do it the dirty way. You can do it using normal commands (as in my previous comment) and get the same result, except with reflogs intact and no chance of borking things. And it’s guaranteed to work, since you’re not mucking with implementation details.

    – Cascabel

    Nov 16, 2013 at 15:12