Why I’m renaming my default git branches

This month, there has been a renewed interest, apparently boosted by support from high profile organisations such as GitHub in replacing some (at best) inappropriate terms used in version control and software development. From my observation, most developers are interested in exploring these alternatives, and are actively engaging with colleagues to ascertain what might be involved in renaming default branches from the widely used ‘master’ (evoking hurtful imagery of slavery) and using alternatives to ‘blacklist’ and ‘whitelist’ (e.g. ‘blocklist’ and ‘allowlist’). During these discussions, I have so far become aware of three main concerns about taking this approach:

1. Is this really necessary? We don’t mean ‘master’ in that way.

Like many millennials who grew up in the UK, hearing peers deem anything they vaguely disliked “gay” was a daily occurrence. I was well aware that many using it did not mean to be actively homophobic and were simply invoking a context established by others: gay = bad. This lack of intent didn’t make it any less hurtful or isolating as an LGBT youth to hear the word used as a casual insult for everything from an overzealously applied detention to an unsightly pair of trainers. It’s easy to deem something a non-problem when it doesn’t affect you.

Of course, it’s equally inappropriate for me to assume that people of colour are hurt by this terminology based on my own experience as a white person — but if one term is potentially hurtful, and another clearly isn’t, isn’t it worth a small amount of effort to choose the latter? Furthermore, saying “That’s so annoying / unpleasant / bad / your chosen expletive” instead of “That’s so gay” is not only kinder, it’s clearer. No longer do your audience need to understand some culturally ingrained metaphor to know that you mean the word as an insult. No longer do you de facto exclude anyone who does not understand or agree that this is an insult from those who do. To use established language as intended is to include all who would be part of the conversation.

A default Git branch is an established safe state for an application from which changes can be safely initialised. It usually represents the current state of the application as your live users access it. Using this definition, does it really make sense to call a branch ‘master’ rather than ‘main’, ‘base’, or ‘production’?

2. We have so many repositories and scripts, it will be an enormous undertaking to change them all.

Then why not handle it like any other type of technical debt — the same way we regularly go about upgrading dependencies and documentation, migrating to a new cloud platform, or moving from Bash scripts to Dockerfiles? One project at a time, when you can fit it in — every organisation is different and should go at their own pace with respect to their existing workflows and expectation, but slowly and steadily, these improvements can be made.

3. We might use different terms going forward, but we shouldn’t change existing projects; that would be rewriting history and prevent important discussions in the future about why the change was made.

I believe this argument is well-intentioned, and the decision about how to respond to these suggestions, of course, remains with the individual. It is my opinion, however, that this sort of response is a symptom of white privilege. It’s true that British education, in school, at work, and in the wider community, is woefully lacking in honest discussions about our racist past and present, and I appreciate the desire to encourage the opposite.

However, I consider myself a progressive and open-minded person, I’ve been working in software development using these terms for several years, and it never occurred to me until recently to question their use. If, in my early days of development, I had come across a mixture of default branch names, I can’t honestly say my instinct would have been to ask anyone why — it has always been possible to use whatever branch names one likes, and it would be easy to put the discrepancy down to a variety of styles and preferences akin to tabs v spaces. I feel that to leave these historical projects as they are while updating future ones in the hope that it will be educational is to fail to fully commit to a better approach and lend ammunition to those who would advocate “debate” or “asking questions” in order to delay progress and reframe a move towards inclusion and respect as an optional favour that they can choose whether or not to grant; a subtle but key aspect of white supremacy.

History is regularly rewritten as we learn more about ourselves and our past. Software is rewritten for the better when we listen to our users and colleagues. Developers love to create brand-new, better applications for our users, but it would be arrogance to refuse to improve experiences in legacy systems so that future developers might learn something from their shortcomings; our users deserve better. I don’t suppose the vast daily grind of racism will be much lessened by the sort of small changes to vocabulary being advocated here, but I won’t accept the arrogance of white software developers who would compromise on even such a small gesture in order to take less responsibility for our own education. Humanity deserves better.

I don’t want to have to go into work and explain over and over again why it’s wrong to say “That’s so gay” when your IDE crashes. I’m just glad most people have stopped doing it, and they’ve stopped because they saw others had stopped, no ifs, no buts. We committed to making it unacceptable, and I’m going to fully commit to anything I can do, however small, to help establish the truth that white supremacist behaviour of any kind is unacceptable.