TL;DR: Starting from 2023, I will not use the default branch name “master” or whatever “m”-based alternatives (“main” or whatever).
Some argue that renaming from “master” to “main” by Github and Gitlab is a BandAid approach to problems. I recently came to a different way to think about this issue and I decided to switch.
I must admit that I accepted the usage of the default “master” branch name in the past without much thinking. I didn’t question whether it makes sense or not, like I blindly accepted many computing terms. Using the modern nudge theory, we are being nudged to use the (potentially offensive) default name provided by git when we execute the command git init. If the activism to replace this default name has brought anything to the table, the number one thing it brought is asking us to rethink this default name “master”.
There are many ways to defense the usage of the “master” branch name. But the worst argument is that the “master and slave” metaphor has been used in computing for a long time 1. I still remember ATA hard disks used to have a jumper for selecting “master” and “slave”. The reason why it is the worst argument is twofold. First, it is probably no longer okay to use this metaphor anymore because what was “acceptable” in the past by some elite classes for a long time doesn’t mean it is automatically also acceptable/correct/okay now. Think slavery in 1619 and slavery now. Or trepanation (drilling holes in one’s head) in the middle age and trepanation now. Binding the feet of women in Imperial China and binding the feet of women now. Sati (burning alive the widow of a deceased husband to death as a sacrifice) in 17th century India and Sati now. The fact that these things were “acceptable” by some people in the past doesn’t mean they were correct back then or are still correct now. And two wrongs certainly do not make a right.
Second, there isn’t a “master and slave” relationship going on between the “master” branch and other branches in version control. Therefore, the existing usage of the “master and slave” metaphor, accepted or not, has nothing to do with version control. And bringing up the Status Quo of the so-called acceptance of the “master and slave” metaphor in computing is irrelevant. As a matter of fact, even the proponents of using the “master” branch would never call their other branches “slave branches”.
Of course, the word “master” isn’t always associated with slavery. By the same token, the use of “master” in version control isn’t racially motivated. “Master” certainly has other meanings. The Latin word Magister means “teacher” or “host” (The “master” in the sense of “master / slave” is more like Dominus). “Headmaster” means the one who manages a school, the “head teacher”. A master’s degree (in many countries it’s still called “Magister”, for example LL. M. = Legum Magister/-tra) originally means “a license to teach”. “Master of ceremony” is the host of an event. The word can also be a verb. “Mastering a technique” means being acquaintance with a technique.
I think the meaning that the creator of git (Linus Torvalds) had in mind when he decided to use the word “master” is probably the idea of “master and copies” instead 2. In the recording industry (and by extension, software industry), a “master” (e.g. a master tape) is used to make “copies” (not slaves!). “Mastering” is about preparing a master for copying. Software is the same. A master copy of the software is used to produce the big boxes of software such as Windows 95 with 13 floppy disks in it.
For your interest, in my language “master tape” is translated to “mother tape” (母帶). A “mother tape” is used to make copies (拷貝, a homophonic translation). In this sense, “master” makes a little bit sense because other branches could be a copy of the “master” branch at some point. I still don’t think it is the most descriptive way of saying it though. The old school meaning of “master” is more close to the concept of releases. We can also tag a particular commit to mark that as the state of the software one should make copies with.
It highlights the gist of the problem: the hardcoded “master” branch name as the default is not descriptive in many situations. The branch name “master” needs to be renamed. The question is to what?
Starting from git 2.28, a new configuration called “init.defaultBranch” is being introduced. I was wondering why the replacement of “master” wasn’t “default” but “main”.
Having said so, I do agree that “main” is a better branch name than “master”. You can say that the non-default branches are “sidelines”, “secondary” (then why the default branch name isn’t “primary”?), “experimental” / “feature” (then why the default branch name isn’t “production”?). “One cannot not communicate” (but see this). The naming of branches is actually a communicative matter. One can’t have a universal enough default name that can communicate the concept of default branch in all development models. For example, the default branch in the Gitlab flow should be called “pre-production” branch. The default branch in the Gitflow should be called “production” branch. One can’t collapse all of these under “main”. The clause shouldn’t only be replacing potentially offensive “master” with “main”, but using descriptive —default or not— branch names. A descriptive branch name depends on the communicative norm, communicative context and communicative intention.
I will adopt an approach that is neither naming a branch “master” nor “main”. My first inspiration is from the development of actions. The current default branch is the current version underdevelopment ("v2-branch"). Similarly, the development of Drupal also uses version number branch names. The current default branch, as of writing, is "10.1.x".
It semantically makes a lot of sense to name branches according to version. It is descriptive in the communicative norm that semantic versioning is widely adopted. It communicates the context and intention well: Commits in this branch are for a particular version of the software. A new branch with a new version number is branched from an older version branch. Pushing commits to a specific version branch is working on a specific version. “I am working on the v10.1.x branch” means I am working the v10.1.x of the software; not a “master” branch that I don’t know which version is it now. Tacitly, many software development is actually using this approach, even with the “master” branch. emacs, for instance, has branches such as emacs-28 and emacs-29.
From now on, all of my Git repos is transitioning to branch names based on version number. My “init.defaultBranch” is “v0.0”. The initial “v” is not necessary. But I think it looks slightly better.
I’ve read a Mastodon post by Erik Moeller on the legacy of Richard M. Stallman (RMS). You might know that RMS is very pedant on terminology: Free software vs open source software; GNU/Linux vs Linux; even acronym such as LAMP vs GLAMP (I never see anyone says GLAMP). There is a huge list of words to avoid on the official GNU website. Moeller argues that this kind of pedantry on terminology is alienating, not emancipating. In my opinion, activism always starts with the correct language of communication. But if this language correction activity becomes an obsession and even evolves into policing how the people on the same boat with you communicate, that’s alienating.
A good kind of activism is not alienating. The best kind of activism is for one to feel natural to do it 3. If the abolishing of “master” branch is an act of activism, try to make it the good / best kind. The human nature of wanting to use a more descriptive label is universal. And under this nature, it is natural to abandon the “master” label.
Finally, I just wanted to stress that my branch naming approach applies only to my own git repositories. I will still collaborate with people using —in my opinion— not so descriptive branch names such as “master” and “main”. One doesn’t need to agree with my opinion about the descriptiveness of branch names. I am not an activist. Even if I were, my activism is not policing people who are in principle on the same boat with me (we want to working together on some non-proprietary software in public).
Well, there is an even worse way to defense: The opposition of “master” is wokeism “cancel culture”. First of all, this is Argumentum ad hominem. Second, it doesn’t make “master” a good branch name even when the opposition of “master” were wokeism. ↩
See this commit message on his promotion of inclusive terminology in the Linux kernel. ↩
Suppose “promoting the use of free software” is your activism, the best way to make this happen is to make free software the best quality (e.g. the most useful) among all other choices. The argument is then becoming choosing the best, rather than between free and non-free. It is natural to choose the free software and there is no promotion needed. The case in point is the duopoly of R and Python in the data analytic space. Both are free software. One doesn’t need to promote free software in that space. Linux / BSD are similar, at least in the server space. ↩