master vs main
I just started working on my Phase 4 project in the Flatiron School program and was welcomed with a dilemma.
Wait a min; why do I have two base branches? I see a notification to “compare and pull changes” from master to main, but even though main only has a Readme while the master branch has a brand new rails app, when I click on the green “pull” button, it tells me “there isn’t anything to compare” because “main and master are entirely different commit histories”, which then starts to make sense.
Well, I knew the master branch used to be the main (of course, I could easily make the master branch the default by going to the repo Settings->Branches-> changing the default branch to master, but that doesn’t take care of the other branch, and something about my coding experience makes me feel uncomfortable with code bloats (or any kind of bloats, really)
common causes of master and main in a git repo
Little backstory here: starting from “Oct. 1, 2020, any new repositories you create will use main as the default branch, instead of master," according to GitHub. This is one of other steps taken by many organizations to abandon non-inclusive terms that reference slavery
The most common cause of having both main and master branches is because a master branch is pushed into a repo with main as the default branch. This can be due to a lot of reasons. In my case, I initialized my git repo with a README and then set the remote of a new rails project to that repo. Some versions of rails still initialize new apps with master as the default branch, as did mine. So when I git push-ed to the repo, it created a remote master branch that the local branch would track.
use cases
since the ideal flow in github version control is to create new branches for testing and then merging back to the main/master when it is proven that the added code won’t break anything, I don’t think there would be a reason to have two main branches, but if your situation calls for it and, depending on the size of your project, you can manage the complexity that arises from doing so, then there isn’t really anything stopping you from using both.
how to change master to main
there are a lot of resources available on github itself and other sites about this, but it is pretty easy.
If you have a new project and haven’t made any push(es), you can
1. git branch -m master main //this changes the local branch from master to main; if you are on the master branch, you can omit the master
2. git add <files/directory>
3. git commit -m <commit_comments>
4. git push -u origin //origin or whatever name you’ve given to your remote
If you only have master but want to change to main, you can
1. /* rename your remote branch on github */
2. /* rename the local branch using */ git branch -m master main
3. git fetch origin
4. git branch -u origin/main main
Finally, if you have a master and a main and want to switch to main only, you can merge with the main branch. Since the contents of master is the working code, you should be able to “merge” this code into your main directly; if it doesn’t work due to an “unrelated history” error, you can add a — allow-unrelated-histories tag. This step can be done in two ways:
- rename the current branch from master to main, change it’s remote to main, pull down/merge from main, and then push up (this is suitable when there’s nothing important in the main yet)
or
2. create a new local branch called main, set it to track the remote main, pull in the local changes from master (ie merge), (pull down the remote main and resolve conflicts), and then push up
Step 1 code along:
git branch -m master main //renames master to main
git fetch origin //gets the latest commit from the remote
git branch -u origin/main main //makes the local main branch track the remote main branch
git remote set-head origin -a //
git merge origin main --allow-unrelated-history //will allow you to merge the current branch with the remote main branch, and then you’ll be able to push up using normal git push
git push origin --delete master //deletes the unneeded remote master branch
Step 2 code along:
git checkout -b main //creates a new branch main and switches to it NOTE: by default, git checkout -b bases the new branch off the current HEAD; if you change that, make sure your work is in the new branch before deleting the local master
git branch --set-upstream-to=origin/main main //sets the newly created main branch to track the remote main branch
git branch -d master //deletes the local master branch
git push origin :master //updates the remote repo to delete the remote master branch
//if you try pushing but get a "unrelated histories" error, try
git pull origin main --allow-unrelated-histories //fix any conflicts that occur
//then you should be able to push without any problems
questions? google ‘em
feedback? drop a comment!
Resources
- https://www.git-tower.com/learn/git/faq/git-rename-master-to-main/
- https://github.com/rails/rails/pull/40254 //see the discussions about changing “rails new” default branch
- https://gist.github.com/qjhart/4770af321dfe4271ac3071b3152b5682