Your Scripts Assume git init Creates master and Git 3.0 Will Make It main

A new developer encountered issues with tests, failing on her laptop but passing in the Continuous Integration (CI) system. The tests involved creating small repositories to test the release tool. The process involved initializing a repository, committing a file, checking out the "master" branch, and tagging it. However, on her machine, there was no "master" branch.

Her Git configuration was set up to call the first branch "main," causing the checkout to fail and affecting subsequent tests. This discrepancy arose because Git itself did not change its default branch name, while GitHub switched to "main" in 2020. Some CI images had not been updated to use the new default branch name.

The script's behavior varied between machines, and it would continue to do so as Git prepares for version 3.0. The default branch becoming "main" is on the list of breaking changes planned for the new version. Once the build image upgrades to Git 3.0, all scripts that assumed the default branch would no longer work. Developers should stop depending on the default branch name in either direction.

When a script creates a repository, explicitly name the branch using "git init -b" followed by the desired name. This approach has been effective since Git 2.28.

To handle the current branch, scripts should ask for it using "git branch show current." For the main branch of a remote, scripts should query the remote's HEAD. By searching for the word "master" across scripts, CI files, hooks, and release tooling, developers can decide how each one should behave. It is essential to add a job to CI that sets init.defaultBranch to a name that no one uses, such as "trunk" or "banana."

This approach ensures that scripts that pass will not rely on the default branch name, and those that fail were guessing. Ultimately, a default branch name is a decision made by someone else, and they are allowed to change their mind.