Rename default branch from master to main

Discuss your ideas or share your views:

I just noticed this while debugging another PR. The default branch is called master. This year, as a result of BLM, GitHub moved the default branch from „master” to something more neutral („main”).

This issue is about

• giving some history context,
• discussing, whether this project should follow along (not all repo owners do) and
• what will be needed if we do so.

History

Back in June, GitHub announced to move the default branch later this year citing associations to Slave-Mastery. The changes were implemented in October this year.

That caused discussions on the git mailing list, where the actual background was stated:

Git doesn’t use “master-slave” terminology – the “master” comes from the concept of having a “master” from which copies (branches) are made:

https://simple.wikipedia.org/wiki/Master_recording

The concept predates the music business and goes back to middle ages when a guild master would create a “master work” or “master piece” that the apprentices could use for study or for imitation.

https://en.wikipedia.org/wiki/Master_craftsman

So, while I wholeheartedly support using inclusive language, I think git is in the clear here.

There is a draft at IETF to update terminology, too.

However, a few projects switched their terminology way earlier:

• Django (2014)
• Drupal (2014)
• Roslyn (2017, .NET compiler)
• Python (2018)
• Redis (2018)
• Chromium (2019)
• PostgreSQL (2019)
• Jenkins (2019)

Or already migrated / are in the process of migration (note: this also deals with other problematic terms):

• Microsoft and IBM
• Twitter
• RedHat
• MySQL
• OpenBSD
• git
• Android OpenSource Project
• Go
• PHPUnit
• cURL
• OpenZFS
• LinkedIn
• OpenSSL
• Ansible
• PowerShell
• p5.js
• Circuit Python

As you can see, a lot is going on to ban racist terms in software.

Should this repo follow along?

Personally, I’d say yes. To me, „master” is a technical term. I don’t associate it with slavery (but more with craftmanship). But it’s a small change, which doesn’t do much harm (rather a one-off for existing forks) and can help more people feel welcome. That’s why I’d argue it’s worth it.

What’s needed to change?

You can change

• your personal settings and
• freeCodeCamp org settings (org admin permission required?)

Tech Republic says:

• Open pull requests must be targeted to the newly named branch;
• draft releases must be targeted to the newly named branch; and
• branch protection policies must be transferred to the newly named branch.

GitHub’s intention is to ensure that, by the end of the year, all repositories will be able to seamlessly rename their default branch. That means when you rename a branch, GitHub will automatically retarget open pull requests and draft releases and move your branch protection policies. GitHub is also hoping to be able to redirect users who use either git fetch or git clone to move an old branch name to a new branch name.

First thing you should do locally is BACKUP. Then, move your local master to main: git branch -m master main. Push it to GitHub: git push -u origin main Update your HEAD: git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main If your default branch was updated, you can delete the master branch on GitHub: git push origin --delete master (or git push origin :master).

Find more information on GitHub’s support page on renaming.

[allella]

The default branch and the name of the master / main seem to be two different decisions.

Of course, having develop and main/master is a common pattern for isolating the development work from the stable / live branch.

I believe the intention of this issue was renaming master to main.

If we also want to switch the docs and default branch to develop in the same process, then I’d go along with it too. However, I am curious if changing the default would cause problems, like if someone unknowning cloned the project expecting to get a stable branch and ended up in development. If there are issues like that, then the tags and documentation can likely work around them.

[vkWeb]

@Ryuno-Ki we should wait by the end of this year / early Q1 next year as GitHub has planned to release some automation for branch renaming.

For existing repositories, renaming the default branch today causes a set of challenges:

• Open pull requests need to be retargeted to the new branch
• Draft releases need to be retargeted to the new branch
• Branch protection policies need to be transferred to the new branch

By the end of the year, we’ll make it seamless for existing repositories to rename their default branch. When you rename the branch, we’ll retarget your open PRs and draft releases, move your branch protection policies, and more - all automatically. And, we’re also looking into redirecting users who git fetch or git clone the old branch name to the new branch name (with a warning and instructions to update their local clone), so it’s easy for your contributors to move.

Extracted from: https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-