Over the last few years, Git has moved away from the word master as the default name for the primary branch in a new repo.
This is presented as an anti-racist action. We can have a discussion about whether it actually helps effectively counteract racism — to me it seems superficial and performative — but the intent is noble. Additionally, for a tool with the scope and user base scale of Git — the default version control system for basically all software development these days — the simple fact that a subset of people were uncomfortable with the word master is justification enough to change it. Git has to accommodate all software developers; the standard of inoffensiveness to which it must hold itself is much higher than that of an individual or even a medium-sized enterprise. Exceptions to this rule exist — you cannot demand that Git make an explicitly discriminatory change just to please a different group of people, for instance — but this is not that.
None of this, however, entails that the name main that Git now defauls to is actually the ideal alternative. This post will examine a few common and less common options for naming the primary branch in a Git repo, and their respective merits and drawbacks.
mainGit has settled on main as the new default primary branch name.
This is by far the most conservative option: use a widely-understood word that evokes primariness but is not master. The name main is a good drop-in replacement for master, in that it fits well in most existing Git branch naming schemes, and thus it is understandable why the Git developers landed on this option.
Using main is not, however, entirely without drawbacks. Among other things, it fails to take full advantage of the branching metaphor used throughout Git.
trunkIf I were choosing a new default primary branch name for Git today, I would probably call it trunk. As has been pointed out numerous times before, this name fits very well with the "branching tree" metaphor that you see throughout Git.
Among other things, I recently switched my personal global Git configuration file to use trunk for the primary branch in new projects. While I probably will not keep this name in more than a small number of projects (more on my personal naming schemes below), I believe it is the best name for the default primary branch given no other contextual information about the project that the repo contains.
In a couple of cases, I have also seen Git projects use something like main when trunk would clearly be more appropriate for reasons unrelated to how Git is being used. The best example is, of course, Mastodon, where one gets the impression that the opportunity for a brilliant pun was missed.
publicOther semantically-appropriate names exist, though.
These days, I tend to use public for blogs and all other projects wehre it makes sense — i.e. where the project has a clear public-facing version to which "features" (posts, articles, chapters etc) are continuously added.
I would not use this scheme for most software projects, however. The semantic justification for choosing it only exists in a "publishing" context where there is one static-other-than-additions version of the project that the world sees and everything else remains private; this model is less appropriate for a "developing and releasing" context where many versions may remain supported and accessible simultaneously (and the entire project may be open source and thus public in the most literal sense).
develop and productionThis is my default for software projects.
You can have more than one "production" branch if i.e. you have multiple environments, want to keep older versions around (although tags are better for that), etc.
It is also entirely reasonable for many projects to call the production branch something like release — I had to pick one to name the section, but only you can decide which is appropriate for your project. I would probably use production for a service where the production code ran primarily on servers I controlled and release for a project where the user would be downloading a release to install.
In this scenario, either the production branch or the develop branch can be the primary branch. This is largely a matter of taste; in the first scenario, deployments might involve a squash and merge be followed by a rebase of develop onto production, whereas in the latter case you might fast-forward production to the tip of develop when deploying or just create a new production branch for each version.
When I start new software projects these days, the first branch I create is typically called develop. This is ultimately a consequence of the age-old adage that everyone has a testing environment, and truly good teams also have a separate production environment — every project has a development branch, but only when the project hits a level of completeness does it need a production or release branch or branches.
The above list is far from exhaustive.
Among other things, in Git repos holding conlanging projects, I sometimes name the primary branch after the word for main, trunk, or something similar in that conlang (once such a word exists).
I have also long had a semi-fantastical idea of naming git branches as if they were filesystem paths, with features and sub-features treated as if they were subdirectories of the branch they were branched from. I have never actually tried this in practice, however, other than a very small amount of playing around in throwaway repos, during which I realized that Git stores branches as actually filesystem paths and thus can't handle having both <branch> and <branch>/<sub-branch> in the same repo — the former is stored as a regular file named <branch>, which blocks the creation of the directory <branch> which would be needed to store <branch>/<sub-branch>. There is no reason another separator could not be chosen, however.
If there is one thing I want you to take away from this post, it is that there is no one correct way to name Git branches, although there are definitely incorrect ways. This has always been true, but the discussion and subsequent decision to remove the word master provides an opportunity to rethink how you name branches in general.