2055

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Karel Bílek
  • 36,467
  • 31
  • 94
  • 149
  • 3
    Check answers to the very similar question http://stackoverflow.com/q/2862590/151641 – mloskot Apr 25 '12 at 23:29
  • 6
    Had a same problem, however I simply removed the master and renamed another branch to master: http://stackoverflow.com/a/14518201/189673 – jayarjo Jan 25 '13 at 08:52
  • 13
    @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. – joelittlejohn Sep 19 '13 at 09:17

17 Answers17

2509

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
Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 32
    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 '14 at 20:17
  • 1
    If there were branches based off "better_branch" that you wished to continue working on, would you need to keep "better_branch" until those were also merged into master or could you remove "better_branch"? – Woody Sep 12 '14 at 09:16
  • @Woody That's really a completely different question (and I'd encourage you to ask questions as questions), but the short answer is that if you have a branch, none of the commits leading to it are going away, whether or not there's a branch pointing to any of them. Branches are just pointers to commits; removing the branch has no effect on the commits. – Cascabel Sep 12 '14 at 15:40
  • 2
    This is super helpful, yay thanks. The only gotcha for me is I execute the second line of the first part of the solution before absorbing the "if you want your history to be cleaner". Why not just have that second suggestion as _the_ solution? – GreenAsJade Oct 18 '14 at 09:44
  • 3
    Could we just go to the master branch and do `git merge --strategy=theirs better_branch`. Is there such thing? – Pratheep Dec 10 '14 at 10:40
  • More steps needed if you plan to continue development on the old master: - create a new feature branch from a commit just before merging - merge from new master into the new feature branch with --strategy=ours again Unless you do that extra merge, you cannot do normal merge from master, because it will delete changes on the new feature branch – altumano Jan 10 '15 at 22:39
  • 11
    I had to make the second line `git merge --strategy=ours master -m "new master"` for it to work. – incandescentman Jun 04 '15 at 05:07
  • The second line can be somewhat shortened to `git merge -s ours master`. – s.d Oct 23 '15 at 12:07
  • 1
    Why is that better than renaming the current master to master-abandoned and then renaming the better branch to master (see answer by @Dietriech Epp)? The new master should then show the whole history of what we are interested in and master-abandoned shows the whole history of what we are not interested in. Or do I miss anything here? – jpp1 Nov 15 '15 at 16:19
  • 8
    @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 '15 at 16:47
  • Does this keep my old master? I want to basically switch them out. – Jaanus Jan 06 '16 at 15:10
  • 1
    @Jaanus You could certainly create another branch where master is before this, and keep that around. So... depends what you mean by switch. If this is just a private repo and you literally just want to swap names of branches, all you have to do is rename both branches (old -> tmp, new -> old, tmp -> new). – Cascabel Jan 06 '16 at 15:30
  • @Jefromi so you are saying these are just names? There is no special logic behind it, like parent child relationships between branches or something similar? – Jaanus Jan 06 '16 at 15:42
  • 1
    @Jaanus Yes and no. Branches are just names. They point to commits, which have ancestry via parent commits. So you can rename branches all you like and all it affects is names, but if you care about that ancestry, you need to deal with it correctly. For example, the OP here needed the new version of their master branch to have the old version as an ancestor, so they needed to merge, not just rename branches. – Cascabel Jan 06 '16 at 15:49
  • the new master does not retain all the different commits from better_branch. How can I retain all the commits? – ssal Jan 27 '16 at 19:47
  • @ssal Post a new question with more details. I can't even tell from what you said whether the issue is that the idea of this question (and answer) are not actually what you want to do, or if it's the right idea but something went wrong when you tried. – Cascabel Jan 27 '16 at 20:39
  • According to the docs, git merge --strategy=ours master *favours* ours, but still merges yours, except when it doesn't. Clarrification would be good. I will do a revert first just to be sure. – Tuntable Aug 09 '16 at 06:46
  • 4
    If vi editor during merge appears, type :w (for saving) :q (for exiting from vi) – Tomas Kubes Oct 27 '16 at 09:23
  • It's a lot better to simply replace the branch and push force it, when I tried this I ended up in an even weirder state. Just do: git checkout master; git reset --hard new-fixed-master; git push origin master -f; done deal – Gubatron Jan 03 '17 at 21:37
  • 1
    @Gubatron That's not necessarily better, for basically exactly the reason I said in my answer - you've now moved the remote, and everyone who tries to pull will get messed up and have to reset their local master too. If you do what my answer says, it will let yo push without forcing it, and let everyone else pull normally. – Cascabel Jan 03 '17 at 21:44
  • 17
    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! :D – chapeljuice Jun 26 '17 at 18:23
  • Looks great strategy, but what about all the commits in the original master? – Bilal Ahmed Yaseen Sep 11 '17 at 11:47
  • 3
    @Kelvin : Thanks for the clarification... " [This should not be confused with the 'ours' merge strategy](https://git-scm.com/docs/merge-strategies)" But of course! Who in his right mind would confuse "the 'ours' merge strategy" with... the item called "ours" in the section "Merge strategies" in the official Git documentation! :-/ – leonbloy Dec 16 '17 at 21:35
  • 1
    @Jefromi For me, this only made local changes, the remote is still the same. "git merge --strategy=ours master" gives "Already up-to-date". Any idea why? – zed111 Jan 30 '18 at 00:57
  • Replying to the prev comment: so I did a `git push origin master` and now the remote branch has the changes. – zed111 Jan 30 '18 at 01:26
  • for some reason "git merge --strategy=ours --no-commit master" says merge master into better_branch for me. is this what you mean? i was thinking the question was asking for the opposite – thang Sep 09 '19 at 20:33
  • nevermind. it says itt merged, but the code didin't change. strange – thang Sep 09 '19 at 20:38
  • Really saved me here, was doing a rewrite of my project on a separate branch (you can imagine the 500 merge confilcts!) – unixandria Mar 09 '20 at 14:48
  • With respect to this question, after merging a beach to the master and resolving the merge conflicts what is the next step we should follow? – Niroshan Ratnayake Apr 10 '20 at 04:33
  • This helped me very much! NOTE: I had to look up how to insert the comment when Terminal jumps into VI mode and asks for a comment. Here is a link to how I solved that. https://stackoverflow.com/questions/19085807/please-enter-a-commit-message-to-explain-why-this-merge-is-necessary-especially 1. press "i" (i for insert) 2. write your merge message 3. press "esc" (escape) 4. write ":wq" (write & quit) 5. then press enter – Dave Levy Sep 14 '20 at 14:10
  • The second line with the strategy seems always good as I want to keep the master history. – Timo Nov 11 '20 at 14:47
  • How I wish we don't have to do all the plumbing, but perhaps the "Xeroe PARC" or Steve Jobs GUI way of: right click on this branch, choose "Make this branch the master branch" -- "Are you absolutely sure?" – nonopolarity Feb 05 '21 at 14:33
  • What about if we want to switch `master` with `better` and `better` with `master` in their present state, meaning without adding any of those merge commits? – Nike Apr 30 '21 at 21:04
  • Just curious, what is wrong with cloning the repo somewhere else, checkoutm new-master, copy the entire set of files of new-master into a location where master is checked out, commit and push with a message describing what is being done? All histories are preserved. – andrea m. Nov 11 '21 at 11:57
  • 13 years and still going strong! This answer was exactly what I needed. I added --squash to the 4th line to avoid the hundreds of commits that I was merging into master: git merge --squash better_branch – kenswdev Apr 24 '23 at 18:49
  • I tried this strategy, with the undesired effect that it kept commits on master that on apprentice that was squashed into one. Now I have a merged commit history, with both the squashed commit and each individual commit that comprises the squashed. The `--strategy=ours` flag seemingly only favours "better_branch" when there are conflicts. OP wanted to discard any changes on master, which in my case this strategy didn't accomplish. – Pål Bjartan Aug 23 '23 at 11:20
688

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
Trect
  • 2,759
  • 2
  • 30
  • 35
Brandon Howard
  • 6,931
  • 1
  • 10
  • 17
  • 134
    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 03 '17 at 21:35
  • 54
    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](http://stackoverflow.com/a/8888015/1483986) – 7yl4r Mar 27 '17 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 – inetphantom Jun 20 '18 at 14:02
  • 5
    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 '20 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. – Stanley Okpala Nwosa Jul 06 '20 at 01:35
  • What does the git reset --hard better_branch do? Does it reset the current branch to the latest commit of the better_branch? Great answer btw worked for me. – Shrey Joshi Aug 13 '20 at 03:46
  • Does this get rid of commit history of the "old" master? What if I want to someday go back to that? – David Callanan Sep 01 '21 at 10:02
  • You might need `git push -f origin master` instead of `git push -f origin main`. – LC117 Nov 13 '22 at 10:12
  • This worked for me. The accepted answer above only resulted in a merge of the two branches' commit history, keeping changes on master. This will completely overwrite the history on master to correspond with 'better_branch'. – Pål Bjartan Aug 23 '23 at 11:26
82

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
Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • 2
    Thank you. One more question. I am pushing it to github. What will happen on there, if I do this? – Karel Bílek May 04 '10 at 05: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 04 '10 at 06:00
  • 7
    @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 04 '10 at 06:08
  • @Jefromi: If I want the branch named "master" to track some remote branch "master", the dirty way preserves this. – Dietrich Epp May 04 '10 at 21:02
  • 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 05 '10 at 02:43
  • @Jefromi - There is a very, very good reason to do this - when you're rewriting the history to remove accidental commits via `filter-branch`. You have to create a whole new branch to do that, and then delete the original history. – Fake Name Nov 16 '13 at 13:32
  • 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 '13 at 15:12
  • @Cascabel (formerly Jefromi) if I want a feature branch to become `master` and the master branch to become `feature`, then I just do what you suggested in your comment, which is: `git branch old-master master; git branch -f master feature`? I wonder why your answer and all the other answers don't suggest this? It looks so much simpler and better than the rest. Dietrich do you agree? Isn't this better than your "clean" way (which you are telling people "not" to do) and "dirty" way (which you are calling "dirty" meaning you don't like it either)? – Nike Apr 30 '21 at 21:12
  • @user1271772: The reason I say "don't" is because that command destroys data. Feel free to run that command if you understand which data it destroys, and you want that data destroyed. – Dietrich Epp Apr 30 '21 at 22:51
  • @DietrichEpp Do you agree that Cascabel's solution in my rent comment (3 hours ago) is better? If not why is yours better? – Nike May 01 '21 at 00:31
  • @user1271772: I don't think one is better than the other. The question is: what do **you** want? Do you want history to follow the new branch? Or do you want history to follow the old branch, with a merge? – Dietrich Epp May 01 '21 at 01:29
  • @DietrichEpp We badly messed up Master by doing dozens of commits to get to the same point we got in another branch (call this branch "Feature") with only 2 commits. So now I want Feature to become Master, so from now on we only make commits on top of Feature (which would be the new Master). The old Master can then be renamed to be called "Feature" since it preserves the history of the dozens of commits we did to get that feature implemented. We will probably never add more commits to the old Master (which would now be called "Feature"), but we would like to keep it for historical records. – Nike May 01 '21 at 01:39
  • @user1271772: So the question is whether you want to keep the history as one branch with a merge, or as two separate branches. – Dietrich Epp May 01 '21 at 04:38
  • @DietrichEpp I would like no merges: I want the current "Feature Branch" to become the "Master" that everyone pushes new commits to, and the current "Master branch" to become called something else, to preserve the commit history there for historical purposes (no one will push commits to it anymore)! – Nike May 02 '21 at 05:07
  • @user1271772: Then use the sequence of commands in my answer. All you need to do is rename the branches. – Dietrich Epp May 03 '21 at 00:21
  • @DietrichEpp The clean sequence or the dirty sequence? While waiting for your answer to my last comment, I think I figured out an easier way which was to just delete our feature branch all together, make a new branch from master and call it "feature", then re-do the commits we had in the deleted feature branch, but on the Master branch this time. Now we have the "old master" preserved in the new "feature" branch, and the "new master" looks exactly as our "feature branch" looked before. – Nike May 03 '21 at 00:29
  • @user1271772: The dirty way and the clean way have *mostly* the same effect. – Dietrich Epp May 03 '21 at 01:22
49

Rename the branch to master by:

git branch -M branch_name master
Alan Haggai Alavi
  • 72,802
  • 19
  • 102
  • 127
  • 13
    Unfortunately git doesn't track branch renamings, so if you've already pushed your repo to a remote and others have local changes on their local old master branch, they will be in trouble. – thSoft Mar 31 '15 at 13:30
  • is there a difference between this and `git checkout master&&git reset --hard better_branch`? – wotanii Mar 21 '18 at 14:22
  • @thSoft What if it's only me that's using the repository? – Nike Apr 30 '21 at 21:13
33

From what I understand, you can branch the current branch into an existing branch. In essence, this will overwrite master with whatever you have in the current branch:

git branch -f master HEAD

Once you've done that, you can normally push your local master branch, possibly requiring the force parameter here as well:

git push -f origin master

No merges, no long commands. Simply branch and push— but, yes, this will rewrite history of the master branch, so if you work in a team you have got to know what you're doing.




Alternatively, I found that you can push any branch to the any remote branch, so:

# This will force push the current branch to the remote master
git push -f origin HEAD:master

# Switch current branch to master
git checkout master

# Reset the local master branch to what's on the remote
git reset --hard origin/master
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
fregante
  • 29,050
  • 14
  • 119
  • 159
  • Very simple and worked perfectly! Two simple and easy to understand git commands. My git repo is saved and now looks super clean. Thanks! – thehelix Aug 01 '18 at 05:44
  • @thehelix Why did you choose this solution when some of the higher-voted solutions (that were also there when you wrote your comment) are so much simpler? – Nike Apr 30 '21 at 21:16
33

I found the answer I wanted in the blog post Replace the master branch with another branch in git:

git checkout feature_branch
git merge -s ours --no-commit master
git commit      # Add a message regarding the replacement that you just did
git checkout master
git merge feature_branch

It's essentially the same as Cascabel's answer. Except that the "option" below their solution is already embedded in the above code block.

It's easier to find this way.

I'm adding this as a new answer, because if I need this solution later, I want to have all the code I need to use in one code block.

Otherwise, I may copy-and-paste, then read details below to see the line that I should have changed - after I already executed it.

Tomerikoo
  • 18,379
  • 16
  • 47
  • 61
SherylHohman
  • 16,580
  • 17
  • 88
  • 94
  • 1
    Note: The blog post cited (https://git.tutorialhorizon.com/2014/10/05/replace-the-master-branch-with-another-branch-in-git/) is no longer available. – eppineda Feb 01 '23 at 21:59
16

I found this simple method to work the best. It does not rewrite history and all previous check-ins of branch will be appended to the master. Nothing is lost, and you can clearly see what transpired in the commit log.

Objective: Make current state of "branch" the "master"

Working on a branch, commit and push your changes to make sure your local and remote repositories are up to date:

git checkout master      # Set local repository to master
git reset --hard branch  # Force working tree and index to branch
git push origin master    # Update remote repository

After this, your master will be the exact state of your last commit of branch and your master commit log will show all check-ins of the branch.

Peeter Joot
  • 7,848
  • 7
  • 48
  • 82
Mark Dietel
  • 271
  • 3
  • 3
14

The solutions given here (renaming the branch in 'master') don't insist on the consequences for the remote (GitHub) repo:

  • if you hadn't push anything since making that branch, you can rename it and push it without any problem.
  • if you had push master on GitHub, you will need to 'git push -f' the new branch: you can no longer push in a fast forward mode.
    -f
    --force

Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.

If others have already pulled your repo, they won't be able to pull that new master history without replacing their own master with that new GitHub master branch (or dealing with lots of merges).
There are alternatives to a git push --force for public repos.
Jefromi's answer (merging the right changes back to the original master) is one of them.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
13

One can also checkout all files from the other branch into master:

git checkout master
git checkout better_branch -- .

and then commit all changes.

Mo.
  • 26,306
  • 36
  • 159
  • 225
user2064284
  • 131
  • 1
  • 2
7

To add to Cascabel's answer, if you don't want to place a meaningless merge in the history of the source branch, you can create a temporary branch for the ours merge, then throw it away:

git checkout <source>
git checkout -b temp            # temporary branch for merge
git merge -s ours <target>      # create merge commit with contents of <source>
git checkout <target>           # fast forward <target> to merge commit
git merge temp                  # ...
git branch -d temp              # throw temporary branch away

That way the merge commit will only exist in the history of the target branch.

Alternatively, if you don't want to create a merge at all, you can simply grab the contents of source and use them for a new commit on target:

git checkout <source>                          # fill index with contents of <source>
git symbolic-ref HEAD <target>                 # tell git we're committing on <target>
git commit -m "Setting contents to <source>"   # make an ordinary commit with the contents of <source>
Nike
  • 1,223
  • 2
  • 19
  • 42
staafl
  • 3,147
  • 1
  • 28
  • 23
3

My way of doing things is the following

#Backup branch
git checkout -b master_backup
git push origin master_backup
git checkout master
#Hard Reset master branch to the last common commit
git reset --hard e8c8597
#Merge
git merge develop
ar-g
  • 3,417
  • 2
  • 28
  • 39
3

For me, I wanted my develop branch to be back to the master after it was ahead.

While on develop:

git checkout master
git pull

git checkout develop
git pull

git reset --hard origin/master
git push -f
knittl
  • 246,190
  • 53
  • 318
  • 364
Braden Borman
  • 309
  • 1
  • 8
2

If you are using eGit in Eclipse:

  • Right click on the project node.
  • Choose Team → then Advanced → then Rename branch
  • Then expand the remote tracking folder.
  • Choose the branch with the wrong name, then click the rename button, rename it to whatever the new name.
  • Choose the new master, then rename it to master.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Junchen Liu
  • 5,435
  • 10
  • 51
  • 62
  • I did that but not sure whether it worked. On github, nothing changed but on git extensions I can see the branch were renamed. – Pramod Jan 25 '19 at 07:33
1

The following steps are performed in the Git browser powered by Atlassian (Bitbucket server)

Making {current-branch} as master

  1. Make a branch out of master and name it “master-duplicate”.
  2. Make a branch out of {current-branch} and name it “{current-branch}-copy”.
  3. In repository setting (Bitbucket) change “Default Branch” to point at “master-duplicate” (without this step, you will not be able to delete master - “In the Next step”).
  4. Delete “master” branch - I did this step from source tree (you can do it from the CLI or Git browser)
  5. Rename “{current-branch}” to “master” and push to repository (this will create a new “master” branch still “{current-branch}” will exist).
  6. In repository settings, change “Default Branch” to point at “master”.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Purushothaman
  • 417
  • 4
  • 6
1

I know this is not what OP wanted, but you can do this if you know you will have a similar problem to OP in the future.

So here's your situation,

  1. You need a branch that has new excellent new breaking features but is not prod currently. You have plans to make it prod in the future.
  2. Your current prod branch (master) is running fine but is boring. You might make some minor changes to it.
  3. You want to keep the current master (prod) branch safe for the future if later you need it.

If this feels confusing, see the below diagram of the bad situation.

*bad situation*
initial master   --->           added boring changes       ----merge---> you loose boring
            \                                                /
             ---> (awesome branch) added awesome changes ---

To solve this( i.e. to stop the loss of boring), do the following Basically,

  1. Create a copy of your current master by doing git branch boring Replace boring with whatever name you want to keep
  2. Now, you can add new awesome features to your master branch and add boring features to the boring branch.
  3. You can still keep updating the boring branch and maybe use it to never merge it to master. You will not lose the boring features.
  4. Your master branch will have awesome features.

So,

*good situation*
 initial master   --->     added awesome changes     --->    Final master(awesome) branch
                \
                 --->   (boring branch) added boring changes  ---> Dont merge to master  --X-->
Anuraag Barde
  • 399
  • 3
  • 9
  • Can you please change copy and paste your code into `code` blocks rather than using screenshot images? It's considered bad practice to use screenshots (it's less searchable, can't be read by software for the blind, can't be copy-pasted, etc.) – Nike Apr 30 '21 at 21:33
  • @user1271772 I actually tried doing that instead of taking images (that's why the content of the image is in ascii), but stackoverflow messed up the words, if viewed in a mobile/smaller device, it would not make any sense. Thats why I decided to keep it in an image form. Thanks for the intimation though. – Anuraag Barde May 01 '21 at 09:55
  • It looks the same, except for and extra `--X-->` in this version compared to the screenshot. Which words are messed up? – Nike May 08 '21 at 17:24
  • 1
    It looks like it worked. There was some issue with inserting a code block after an ordered list. Some trial and error involving whitespace fixed that up. Thanks again. – Anuraag Barde May 09 '21 at 11:13
  • Yea I guess you had to add the `so` to it. I was the one that gave you the +1 when you had -1, so I can't upvote again, but thanks for fixing it. – Nike May 09 '21 at 21:02
1

Just go to the gitlab or github website and find for settings.

Then under settings find for repository.

There find for default branch, expand it and you can get the options to rename it or change it to other branch.

I tried this in gitlab and it worked.

-2

I'm surprised this isn't an answer here. This is what I did.

  1. Made 2 copies of the repo in my filesystem in different directories, one with master and one with the branch.
  2. Copied (manually) all files from the branch to master
  3. Committed the changes to master.

This way, there is a single commit with all the differences included, the commit history is preserved, and no hard force pushes are required.

user37216
  • 11
  • 2