Git has officially changed its default branch name from master to main for new repositories. This update reflects a broader industry shift toward more inclusive language in software development workflows. You can easily align your local Git environment with this new standard by updating your global configuration settings.
The Shift Toward Inclusive Language
In October 2020, GitHub announced that it would change the default branch name for all new repositories from master to main. This decision was not merely cosmetic but reflected a conscious effort by the technology community to adopt more inclusive terminology. The term "master" and "slave" have historical connotations related to slavery, which many developers found uncomfortable and inappropriate for modern collaborative environments.
This change did not retroactively affect existing repositories. Projects created before the announcement continued to use master as their primary branch unless the repository owner manually renamed it. However, the ecosystem rapidly adapted, with major platforms like GitLab and Bitbucket following suit or offering similar defaults. As a result, main has become the de facto standard for new codebases across the industry.
Configuring Your Local Git Environment
If you are setting up a new machine or want to ensure consistency across all your projects, you should update your local Git configuration. This ensures that every new repository you initialize starts with main instead of master. To do this, you need to modify your global Git config file using the command line.
Open your terminal or command prompt and run the following command:
git config --global init.defaultBranch mainThis command tells Git to use main as the initial branch name whenever you create a new repository using git init or clone a remote repository without specifying a branch. It is a simple one-line fix that permanently changes the behavior of your local Git installation.
Renaming Existing Branches
Updating your global configuration only affects future repositories. If you already have local repositories on your machine that were initialized with master, you will need to rename the branches manually. This process involves two steps: renaming the local branch and updating the upstream tracking reference if the branch is pushed to a remote server.
First, switch to the branch you wish to rename:
git checkout masterNext, rename the branch locally:
git branch -m mainIf you have already pushed this branch to a remote repository (such as GitHub, GitLab, or Bitbucket), you must also update the remote reference. Delete the old master branch on the remote and set the new main branch to track the remote:
git push origin -u mainSome remote services may require you to manually delete the old master branch through their web interface or API after you have pushed the new main branch. Always check the specific requirements of your hosting provider.
Impact on CI/CD Pipelines
Automated build systems and continuous integration pipelines often rely on hardcoded branch names. If your project uses tools like Jenkins, GitHub Actions, or GitLab CI, you must update your configuration files to reflect the new branch name. Look for references to master in your pipeline scripts, webhook settings, and protection rules.
For example, in GitHub Actions, workflow files might trigger on pushes to master. You should update these triggers to listen for main instead. Similarly, branch protection rules that previously applied to master need to be migrated to main to maintain security standards. Failing to update these configurations can lead to broken builds or unprotected code bases.
While this transition represents a significant cultural shift in the developer community, the technical implications are manageable. By updating your local configuration and renaming existing branches, you can seamlessly adapt to the new standard. This ensures your development workflow remains consistent with modern best practices and inclusive language guidelines.
Frequently Asked Questions
Will renaming my branch break my existing code?
No, renaming a branch does not alter the commit history or the code contained within it. The commits remain intact, and the content is preserved exactly as it was. You only need to update any external references, such as pull request links or CI/CD configurations, to point to the new branch name.
How do I revert to using master as the default?
You can revert to the old behavior by running git config --global init.defaultBranch master. However, this is generally discouraged as most modern tools and collaborators expect main. Reverting may cause confusion when working with newer versions of Git or interacting with cloud-based repositories.
Does this change affect tags or releases?
No, tags and releases are independent of branch names. A tag points to a specific commit regardless of which branch that commit belongs to. Renaming the default branch does not impact how tags are created, listed, or deployed. You can continue to manage releases exactly as you did before.
What happens if I clone an old repository?
When you clone a repository that still uses master, Git will automatically check out that branch. Your local configuration for init.defaultBranch only affects new repositories created via git init or new clones where the remote default has been updated. Existing remote defaults are respected during cloning.
Can I use a different name entirely?
Yes, you can configure Git to use any name you prefer by changing the init.defaultBranch setting. For example, you could set it to trunk or development. However, deviating from the common standard may create friction when collaborating with others who expect main.