GitHub Says Goodbye to 'Master' as the Default Branch Name

GitHub confirmed this week that new repositories will soon default to a branch called main instead of the long-standing master. The announcement came Friday, June 12, and it’s landing squarely in the middle of the broader reckoning happening across tech right now, as the industry looks hard at terminology that traces back to slavery — master/slave in particular has been on the chopping block in various corners of software for years, and the killing of George Floyd and the protests that followed have clearly accelerated the conversation.

If you’ve been anywhere near a codebase in the last couple of weeks, you’ve probably seen this coming. Twitter engineering already announced it’s dropping master/slave and whitelist/blacklist from its internal style guide. Several open-source projects and companies have been quietly renaming branches on their own for a while now — GitHub just made it official at the platform level, which matters because GitHub’s defaults are, for better or worse, the defaults most developers never think to question.

What’s actually changing

To be clear about scope: this is not retroactive. Existing repos keep whatever branch name they already have. If your project uses master today, it’ll keep using master tomorrow unless you go rename it yourself. What’s changing is the default that gets applied when you spin up a new repo on GitHub — git init locally still gives you master unless you configure it otherwise, since that default lives in Git itself, not GitHub. So there’s a bit of a gap here between what GitHub does and what the underlying tool does, and it’ll be interesting to see whether that gap closes or just becomes a permanent asterisk.

GitHub hasn’t published a hard date for when the new default flips on, just that it’s coming. Given how these platform-wide changes usually roll out, I’d guess we’re looking at weeks rather than days, but that’s a guess.

The practical annoyance, and why it’s worth it anyway

I’ll be honest: this is going to cause a small, steady trickle of friction. CI configs that hardcode master as the branch to deploy from. Documentation and tutorials scattered across the internet that reference git checkout master. Scripts, Makefiles, and onboarding docs at thousands of companies. None of that breaks overnight, but all of it is technical debt now, in the sense that it’s referencing a name that’s on its way out.

That said, renaming a default branch is about as low-cost a form of allyship as software engineering offers. It doesn’t touch data models, doesn’t change APIs, doesn’t require anyone to relearn Git semantics — main behaves exactly like master behaved. The only real cost is muscle memory and some find-and-replace across docs. Given that the upside is removing language a lot of people find genuinely painful, the trade seems obviously worth it.

The bigger question in my mind is what happens to Git itself, and to the huge back catalog of existing repos. GitHub can nudge new projects toward main, but the long tail of master branches on active projects — including plenty of extremely widely used open-source infrastructure — isn’t going anywhere fast. Renaming a branch on a project with external contributors, forks, and CI hooks pointed at it is a real migration, not a checkbox. I expect we’ll be living with both names side by side for a long time yet.