There are a lot of cringe-worthy terms in technical jargon. One of the most common is master in the context of Git repositories and database servers.

Frequently, the terms aren’t just exclusionary, they’re also bad metaphors, as Erin McKean points out in an interview with Iron.

For example, the master branch in Git doesn’t really share any meaningful characteristics with a slave owner, it doesn’t own or control the other branches, and it isn’t, you know… evil. Instead, it’s much more analogous to the trunk of a tree, which is one of the rare examples of where Subversion is better than Git (the other being externals).

Depending on the context, there are many other terms which are more descriptive and meaningful: production, stable, release, develop, base, default, trunk, main, primary.

McKean goes on to say:

…it’s all about what you prioritize. Are you going to prioritize a conventional somewhat clunky, not truly evocative metaphor… over real human beings, having real problems with the terminology?

Especially if the people having problems with the terminology, if it actually affected their lives. There are people alive today who are only a couple of generations away from slavery. There are people who have escaped enslavement in countries in the world, today.

This is not an academic question. I’m generally of the opinion, if there’s a choice between language and people… then choose the people.

I think that’s the correct conclusion, and have started slowly renaming the master branch in my projects. Switching is fairly straight-forward, here’s an example of renaming master to develop:

git checkout master
git checkout -b develop
git push -u origin develop
git remote set-head origin develop # https://stackoverflow.com/a/49560949/450127

# Verify that develop exists locally and remotely, and that it matches `master` exactly.
# Then go to https://github.com/{user}/{repo}/settings/branches, and set `develop` as the default branch.

git branch -D master
git push --delete origin master

Note that doing the above will close any open pull requests that are being proposed for master, but it only takes a few clicks to re-compare a PR’s branch to the new one, and open a new PR. There isn’t a way to port over comments, etc, but the old PR can be linked to for reference.

Obviously, you can avoid that in new projects by just using a descriptive name from the beginning.