No More Git master

A few years ago, I am uncertain how many, but less than 10, I started to notice people being quite upset with some of the names in technology.

I started programming with a lot of ideas about how to better use language to make computer programs more descriptive, so I had a lot of sympathy already, but there were differences in rationale. The main difference was that the other people who are asking for such change, are doing so to reduce harm.

In recent weeks with the high-profile deaths and injuries of people based on racial inequality, the pace of change has increased.

One of the changes is to get away from terminology, such as master, slave. It never had any merit, and words such as primary, replica, and "mainline", "production", "current" are better replacements without the negative historical context.

Change can be hard

Yesterday, I made my own script using Git to try to create a renamed primary branch. Yesterday in IndieWeb chat it was pointed out that just renaming might not be enough. CI / CD pipeline, helper scripts and even code itself may have knowledge of a master branch. Although problematic, this is not about solving those issues. Most are some form of constant replacement.

It did not take long, but hit problems rather quickly, even when solving a fraction of a problem.

Basically, the primary branch is protected by GitHub, preventing removal or promotion using just Git. Atop that branches may or may-not exist. I have not encountered that outside of GitHub, but it could be fair to assume GitLab, Bitbucket and similar systems will have similar behaviour.

Humans make change hard

I will skip over the human side of change being hard, but I see a few broad groups.

  • People without the knowledge of the issue.
  • People without the knowledge of fixing the issue.
  • People who are ignorant or petulant.
  • People who will deliberately continue, despite understanding their choice of words can cause harm.

I hope that by being a part of solving this problem, I can help people to be a little less awful.

Other peoples code

Upon sharing my code in IndieWeb chat, mentioning some of the issues I had encountered Jacky Alcine linked me to an alternative Gist using the GitHub API, rather than the Git standard tooling I had chosen.

It took me a while to get used to approach, and the original script not working for me immediately did not help that. But there was an existing issue which hinted at a solution.

So, I just started hacking

I totally did not just start hacking. When faced with undesirable behaviour, you should not either. An issue mentioned that a list of repository branches would be returned from GitHub.

I have interacted enough with the GitHub API, to know it paginates results. I was aware that without parsing a potentially large number of pages, it would be unlikely that the primary branch could be solved by using the list.

The script was already issuing a PATCH HTTP request though, so I guessed there might be a GET HTTP handler for the same route. I could borrow conventions of the script to retrieve the name of the default branch instead of setting it.

I also knew that username and Organization values could be used in the API to get information about those things, as well as list repositories. I Reasoned that branches might also be referable by name. I got lucky and did not need to read API docs. I tried all these out in an Ubuntu VM outside of altering the repo shell script. This allowed me a little more control and meant I did not need to worry about putting down this work and picking it up later.

This is why I called this hacking.

Some better practices

  • Read the documentation for the API you are going to interact with.
  • Work out a plan of action and write repeatable tests for experiments.
  • Setup a CI / CD pipeline before making changes so that you always push forward.

Cleaning up

After hacking away for a while, I got my PR merged and moved onto other improvements like avoiding typing or referencing my GitHub Token.

At first, I had wanted to preserve argument order. The repo owner did not want to do that, so I made changes they requested as well as addressing a bug I had introduced when allowing usage without a typed or interpolated token.

I also modified some Python so that I could find all repositories with a master branch for an Organization or user. This helped me to generate a list of commands to run later.

User repositories

curl \
	--silent \
	--header "Authorization: token $GITHUB_TOKEN" \
	--header "Content-Type: application/json" \
	"" |
		python -c 'import sys, json; repos = json.load(sys.stdin); master_repos = [ repo["full_name"] for repo in repos if repo["default_branch"] == "master"]; print("\n".join(master_repos))'

Organization repositories

curl \
	--silent \
	--header "Authorization: token $GITHUB_TOKEN" \
	--header "Content-Type: application/json" \
	"" |
		python -c 'import sys, json; repos = json.load(sys.stdin); master_repos = [ repo["full_name"] for repo in repos if repo["default_branch"] == "master"]; print("\n".join(master_repos))'


If you run the above with your own organisation or user. Please make sure you do not forget to replace my name and organisation with your own. You should also consider using the page query string parameter if you have more than 30 repositories. It looks like this.


I Hope if anyone reads this, they do choose to work on updating their personal, hopefully business repositories. It is a small change, but one that could be important in putting a painful past behind us to move forward together.

By Lewis Cowles