A new developer joined
and ran the tests.
Fourteen failed
on her laptop
and passed in CI.
All of them
in the same file.
The tests built little repositories
to try the release tool on.
git init in a temporary folder,
commit a file,
then check out master
and tag it.
On her machine
there was no master.
Her Git was set up
to call the first branch main.
So the checkout failed,
and every test after it.
Nobody's code had changed.
Only the name
Git picks
when you do not pick one.
GitHub switched
its new repositories to main
back in 2020.
Git itself did not.
Plain git init
still says master,
unless you have set
init.defaultBranch
in your config.
Many people have.
Many CI images have not.
So the same script
already behaves differently
on two machines in your team.
And it will not stay that way.
Git keeps a list
of the breaking changes
planned for version 3.0.
The default branch
becoming main
is on it.
On the day
your build image upgrades,
every script that quietly assumed master
will learn otherwise
at once.
So stop depending
on the default
in either direction.
When a script creates a repository,
name the branch.
git init dash b,
with the name you want.
That has worked
since Git 2.28.
When a script needs
the current branch,
ask for it.
git branch show current.
When it needs
the main branch of a remote,
ask the remote.
Its HEAD knows.
Then search your scripts,
your CI files,
your hooks
and your release tooling
for the word master,
and decide each one on purpose.
And add one job to CI
that sets init.defaultBranch
to a name nobody uses.
Trunk,
or banana.
Anything that still passes
does not care.
Anything that fails
was guessing.
A default
is a decision
somebody else made for you.
They are allowed
to change their mind.
– Serguey Asael Shinder
