Personally, I think the argument that a master branch is insensitive is more than justifiable. No further discussion is really needed. However – seeing as further discussion appears to raging around the interwebs – I also think that it's a terrible naming convention that only confuses matters in the first place. I remember when I started learning Git, I thought the "master branch" had some kind of special powers. Well, it doesn't. It doesn't control the other branches, it doesn't enforce certain behaviour, it's really not special at all.
Once you realise that "master" is a name that poorly describes what it actually does you begin to wonder why people haven't been challenging it for years. Programmers fight over variable naming all day, every day, and yet here's a variable that's practically become an industry standard and it doesn't make any sense. It isn't a "master" as in the typical (and unambiguously problematic) engineering concept of a master/slave relationship, because information and instructions flow in both directions[1]. Similarly, it isn't a "master copy" because it is mutable and frequently changes. The "master" branch could serve – and most likely does serve – as the source of truth for your repository[2] but its effective "truthiness" is always in flux. What's more, the degree to which that truth-level fluctuates differs from team-to-team, organisation-to-organisation.
The conclusion to my mind is that "master" just isn't a very good analogy. I've seen a lot of people advocating for "main" or "production" (or "prod", "prd", "live" or some other variation) and I think that's clearly a step in the right direction. It's semantically clearer as to what that specific branch is for and allows organisations to customise the name to fit internal language conventions or even product terminology.
Except, I still find it weird to consider the "main" branch as, well, a branch. What is it a branch of? It doesn't branch from anything else, it's the thing which everything else branches from; it's the foundations, in a sense. As a result, I personally feel that referring to it as the "master branch" is doubly wrong: it isn't a "master" and it isn't a "branch". To be clear, I find the whole branch analogy surprisingly helpful. It was the thing that clicked with Git fastest when I was first trying to wrap my head around how it worked, so I have a certain level of fondness for the concept. Okay, so if "branch" is a useful analogy and we also need a name for the place all branches originate, why not extend the analogy? Instead of "master branch", let's just call it a trunk. Y'know, like a tree 🌳
Now I'm not saying that you must call it a trunk. For starters, something like "production" is clearly more descriptive of the role that the code contained within the trunk does, and I'm all for simple, meaningful naming conventions. Also, the "tree" analogy may not be as obvious for everyone as it is to me and it's certainly rooted (heh) in the English language, potentially making it inaccessible to non-English speakers or problematic for translation in some languages. Plus, as I've seen pointed out elsewhere, one of the benefits of "main" is that it uses some of the same letters that we're used to, so you won't be battling muscle memory if you make the switch. "Main" is also (marginally) shorter than "trunk" (though both are obviously better than "master").
Personally, I think an ideal route for any organisation or project is to simply decide on the best fit for them. It makes little sense that the foundational layer of a repository would have the same name for all situations, which is probably why it's so incredibly easy to change it from "master" in the first place. That more organisations aren't already using a different default just feels like an oversight on their behalf. Still, on personal projects, or possibly those that are targeted towards less technically-savvy, English-speaking audiences, I think there's some mileage in the trunk → branch analogy. It's certainly what I'll be using on personal projects moving forward[3], starting with theAdhocracy which made the switch yesterday.
Incidentally – and again, I understand this is an indie and not-particularly-complex website so YMMV – it took me about three minutes end-to-end to make that switch. It was just a few command-line requests and a settings change in GitHub (process and original source noted here), then repointing my Netlify pipeline to "trunk" and creating a new build hook for Craft. Even deleting the old "master" branch was less than 30 seconds. As I say, it was uncomplicated for me because only a few services were connected to Git, but based on my own research (see further reading) and conversations on the IndieWeb chat channels it seems like a lot of repositories would be in a similar position. For less than five minutes work, improving the fundamental semantics of my codebase and making it more inclusive feels like a very positive step.
