Sorting out my Main and Master Branches

Jonelle Noelani Yacapin
CodeX
Published in
7 min readMay 11, 2021
Photo by Raimond Klavins on Unsplash

I began a new project just as I’ve always done. Created a new directory locally with basic HTML and JavaScript files. Then, went to GitHub to create a new repo. Yadda yadda yadda…

I coded the rest of the day away and pushed it all to GitHub.

The next day, I looked at the heat map on my GitHub profile and noticed none of my work was showing up. No green. I checked the repo and it’s all there, thank goodness. It’s all on the ‘master’ branch, like usual, but the default branch is ‘main’. What is going on and how do I fix this?

Well, I didn’t do everything exaaaaaactly like I normally do. This time I was feeling more daring and added a license when I created the repo. And, it’s this license that’s the only thing on this main branch. Meanwhile, all my work is on the master branch.

Main vs Master

Now, I’ve seen the idea of a main branch pop up a few times when reading about Git but I just thought it was some sort of best practice to have a main branch instead of a master branch. I also though maybe some text editors default to a main branch vs a master branch. Nowhere did these articles I read on Git state if it was mandatory nor did anyone explain the reason behind it.

Main and master are essentially interchangeable. Or rather, they both just operate like any other branch to where you can rename, delete them etc. And as my project has proven, you can have both!

For those of us who are late to receive the news, as of October 1, 2020, “all new Git repositories on GitHub will be named ‘main’ instead of ‘master’.”

For me, this only seemed to kick in when I randomly decided to include a license when I created my repo. Otherwise, all my repos have defaulted to a master branch.

This is in response to the Black Lives Matter protests of summer 2020 and is apart of a bigger effort to remove references to “master” in the context of “slavery” to be more inclusive. Other terms that are being phased out that I have never heard used in the context of tech: slave, blacklist and whitelist.

How Do I Fix This?

Locally, I only have a master branch.

My GitHub repo, on the other hand, has a main branch with the license. When I linked it with my local project and pushed all the changes it created a master branch in my repo with all the commits/work I’ve done.

Now, I have this disaster where the master branch in my repo is several commits ahead of main yet 1 commit behind main. :confused emoji:

I’ve never had to deal with this.

A couple of articles have listed some simple and easy steps to fix this kerfuffle.

I’m going to follow the steps in this article by Steven M. Mortimer on R-bloggers and see how smooth this goes. He states he made the necessary changes in under a minute with these 5 simple steps.

Step 1 — Move the ‘master’ branch to ‘main’

git branch -m master main

After running this command, locally I now only have a main branch with the commit history from the master branch. No more master branch. This was a nice easy way to “rename” the branch without messing anything up.

Step 2 — Push ‘main’ to remote repo

git push -u origin main

This will push the main branch to the GitHub repo. I believe the “-u” (shorthand for “upstream”) sets up tracking with the remote branch in the GitHub repo to kind of serve as “bookmarks”.

Holdup, this didn’t work for me.

failed to push some refs

Updates were rejected because the remote contains work that you do not have locally. (That darn license on the remote main branch.). This is usually caused by another repository pushing to the same ref. You may want to first integrate the remote changes (e.g., ‘git pull …”) before pushing again. See the ‘Note about fast-forwards’ in ‘git push — -help’ for details.

So, I tried git pull

Error: There is no tracking information for the current branch.
Please specify which branch you want to merge with.

git pull error

Then, I tried git pull origin main

refusing to merge unrelated histories

Alright, it doesn’t like the fact that the local main (formerly named master) and the GitHub remote main have completely separate commit histories. I’m going to try to tell it that it’s ok to allow unrelated histories.

git pull origin main --allow-unrelated-histories
merge made by the ‘recursive’ strategy

Now, I have a local license file with my HTML and JS files.

HTML, JS and LICENSE files

If everything is now successfully merged, I should be able to push these changes now to GitHub.

One more time…

git push -u origin main
branch ‘main’ set up to track remote branch ‘main’ from ‘origin’

Success! GitHub is looking great. Everything is there. But, we’re not done yet.

Step 3 — Point HEAD to ‘main’ branch

I have a confession to make. In my flurry to figure out git pull in the previous step, I slipped in a…

git remote set-head origin main

I found this idea in this stack overflow.

Mortimer, on the other hand, suggest this command in his article:

git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

I don’t fully understand all the finer details but, we basically need to make sure the pointer/HEAD is on the main branch in GitHub so that everything lines up how we want it.

To check and see where the HEAD is pointing to:

git branch -a
branches and HEAD

Step 4 — Change default branch to ‘main’ on GitHub site

The whole point of transitioning from master to main is to have ‘main’ be the default branch. By this point, GitHub seems to do this automatically for the most part. Except for, based on personal experience, when repos are created without a license which leads to ‘master’ being the default branch.

On second thought, now that I’m more aware about all of this, if I change the branch name locally from ‘master’ to ‘main’ before I initialize or push anything, the default branch will be ‘main. So, it really just depends on the name of the branch the initially gets pushed to GitHub in this case.

If you need to, or want to, change your default branch in GitHub, feel free to follow Mortimers’ steps here:

Step 5 — Delete ‘master’ branch on the remote repo

git push origin --delete master
deleted master

Goodbye forever!

only the main branch remains

Final Words

I am totally onboard with working on a main branch and doing away with terminology like ‘master’ in my workflow.

Maybe I need to look into a way to have main be the default branch name on my VS Code Editor.

Otherwise, I just need to make sure that the very first thing I do when I begin a new project, is to change the branch name from master to main.

Live and learn!

--

--

Jonelle Noelani Yacapin
CodeX
Writer for

Certified Sommelier and Flatiron School Software Engineering Grad