A few years back some of the bigger tech companies decided to start changing the terminology that they use to make it more incluse and accurate. In many cases I think these are good choices, like moving away from male/female connectors to plug/socket connectors. Some can be changed into multiple forms, depending on the actual purpose, which is much more accurate as well as offering more inclusive language, like master/slave to primary/secondary or controller/worker.
But there are some places where the approach taken really bothers me. One place that I feel this is with the move to change the name ‘master’ as used in version control. Here there is no connotation of master-slave terminology that is a holdover from past injustices, and rather the term ‘master’ refers to the idea of exactness that a master record of information holds. So why change it?
I am also bothered that many technology companies attempt to push this change on users without offering them a reasonable explanation, alternatives, or the ability to opt out. In one egregious example, if you look at an uninitialized GitHub repository, the code they give you includes additional commands to change your local branch name to ‘main’. This really annoys me for multiple reasons:
Security – No-one should be adding random lines of code into areas where the author knows they will be copy and pasted, when those additional lines don’t contribute to the exact function being used. Ideally we need to be training developers, particularly novices that would be more likely to copy and paste code, to clearly inspect every command that they are about to paste, and adding extra ones without clear functional value does not help.
Respect – No-one should be using their own motivations, however well placed, to change someone else’s setup. Even if I disagree that someone has Chrome installed as their browser, I don’t just go and install Vivaldi for them, maybe their workflow requires it. Even if I disagree that someone’s TV has frame interpolation turned on, I don’t go into their living room and turn it off, maybe they like it.
Interference – The manner in which GitHub does this completely beaks the git workflow if someone already happens to be using branches. The code doesn’t just change ‘master’ to ‘main’, it changes any branch name to ‘main’, even if the user already has another preference. If the user wants to push a ‘gh-pages’ branch first, this breaks their workflow completely. It could also mess up branch management generally if you weren’t aware of what happened.
Inclusivity – You should not change your language because someone else tells you to, least of all a massive tech company. That results in performative action, and could in turn mean you miss key discussions to resolve other inadequacies in your processes. When dealing with issues like inclusivity it is important to actually have a discussion within your own working group, not just take a document of banned words from some other company’s HR team and call it a day.
I also think that, if we’re to have a real discussion about it, ‘main’ is a stupid default branch name.
Whatever you’re currently working on will be your ‘main’ thing. Whether that’s working on testing the product as ready to release, or working on fixing a bug. Developers need systems that are as simple and clear as possible. Ambiguous names could lead to mistakes. If you’re juggling multiple tasks, what is your main task? I could see myself making mistakes.
So if we’re going to change the default name, is there a better one we could pick?
For some VCS ‘trunk’ works well. For centralised VCS like Subversion, where there is a single branch from which all else diverges the mental model that ‘trunk’ evokes works well, it is accurate, and it is inclusive. But I feel it doesn’t make much sense for a decentralised VCS like git.
What about ‘source’? If you already use branches for different purposes, like maintaining a webpage through GitHub or GitLab’s builtin web publishing system, this communicates what the branch is for, and conveys the idea of a source of truth you are working from or comparing against. But it’s a bad idea to name a branch with a name that will likely appear in a directory, as this is an easy way to make mistakes and should be avoided. It also doesn’t really work as a general default when you consider that VCS can be used for many purposes beyond managing source code.
I have though about ‘spine’. The mental model conveys something that everything else is built around, makes it very clear that there is only one thing you’re talking about, but that there could be different networks coming off of it. But using a body metaphor feels a little off.
Given that changing away from master seems to be way things are headed, I don’t gain much by fighting it, and if it makes someone feel more comfortable if they should ever come across my code, I’ll pick something of my own. For now I’m going to try ‘core’. I think that this makes it clear that there’s one major area work is finalised in, it’s socially neutral, it’s distinct from terms that might be used in other VCS paradigms, and it already has a grounded meaning in engineering terms.
Also, it’s only 4 letters long, like ‘main’, and if there’s one thing programmers love, it’s having to type less.
To change your default branch name, this is what you need to add to your main .gitconfig file:
[init]
defaultBranch = your_name_hereDo you have a good personal default choice? Leave a comment.
