GitHub 'master' Branch Becomes 'main'

[tajmone]

@SicroAtGit, I've just realized that since October GitHub has now changed the default branch naming from master to main. This doesn't just affect new projects, which now adopt the new naming convention, but at the end of 2020 GitHub will proceed to auto-rename the master branch to main in all existing repositories.

Here are two links with detailed info on the topic, and providing guidelines on how to embrace the migration without breaking existing projects:

• https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/
• https://github.com/github/renaming

Beside the obvious need for us to be prepared to handle seamlessly the branch name switch in this repository, the main problem is that this is a major change on GitHub side which will make many of the book contents obsolete — particularly the chapter on GitHub.

This might be a problem for us, since as translators we can't take the liberty of changing the default branch names in the book. All we can do is add footnotes that clarify the change.

Since this move on GitHub's part is motivated by socio-political reasons, I wouldn't be surprised if future versions of Git might also adopt this new policy — which would basically make the whole book obsolete when it comes to references to the main branch conventional name.

If that was the case (we need to investigate the issue), we'll have to come up with an elegant solution to the problem — adding a footnote every time the master branch is mentioned is not feasible.

Any thoughts on this?

[SicroAtGit]

I read that GitHub automatically redirects the branch name master to main.

A link to GitHub that contains a branch name .../master/... will be redirected to a link with .../main/.... The same behavior should also apply when working with Git together with GitHub, as mentioned here.

As a result, everything should continue to work smoothly. Sure, it will be confusing if you type master and get main as a result.

Maybe we can find another way to contact the book authors. The corresponding repository is unfortunately lifeless.

If all contact attempts fail, can't we fork the original repository and make the changes? Our translation from German to English would then no longer be based on the original git book repository but on our forked and corrected version.

[tajmone]

As a result, everything should continue to work smoothly.

Let's hope so. I didn't find yet the time to read through all the various articles on this topic, but from a quick sift-through I gathered that there are potential pitfalls to the automated fix.

Also, many repositories rely on third party services, e.g. the Travis CI's build-status badge images contain a reference to master branch in their URL, so I'm not yet sure if these services will also auto-fix the name switch — especially since there's also an option to opt-out from the new naming convention, and thus prevent the automatic switch.

The problem is that these auto-chances affect so many repositories that there's hardly time to fix all of them before new year (e.g. editing the config scripts, and any mention of master in the documents texts and links).

My greatest worries right now is how this might affect forks of projects that opted out of the auto-switch (or the other way around), and what's going to happen with repositories that are synchronized across multiple services (e.g. I have quite a few repos with remotes also pointing to GitLab and Bitbucket), so if these services don't embrace the new naming convention too it might become messy to keep all the remotes in synch if master branch isn't renamed to main on all remotes.

Finally, I have my own Git server running in my Intranet, which I use for local works and backups; so I'll have to update all its repositories too (except that the software I use can't be updated on my NAS due to hardware limitations which force me to use a rather old version of Gitolite).

Frankly, this switch might turn out to be quite an ordeal, and I really wish I didn't miss out its announcement in GitHub's newsletters — if I had come across in September I would have had more time to organize myself.

If all contact attempts fail, can't we fork the original repository and make the changes? Our translation from German to English would then no longer be based on the original git book repository but on our forked and corrected version.

No need to do that, it ultimately boils down to take an editorial decision — i.e. whether we should just add a statement regarding the master/main issue in our foreword, and leave references in the book as they are, or whether we should take the liberty of translating master as main everywhere.

The problem with the latter approach is that in many places the book refers to real repositories that are still in existence, showing some historical logs, and altering those logs might be a dubious editorial choice; and the problem is even more complex when dealing with screenshots. Translating it in some places and not in other would create more confusion than it might help, and would require further notes or asides from us, which is more intrusive than adding a single statement in an editors' foreword.

What bothers me is that the reader will see discrepancies between the book text and the results of the actual commands he tries out (e.g. git init), which then affects every other Git instructions found in the book.

For now, let's see how the switch from master to main is going to affect the Git world beside GitHub — I've read that Apple has embraced this policy too, but couldn't find any news about the actual Git tool and if in the future git init will use main instead (all Google search results are about GitHub, making it hard to dig into how this affects other services and tools).

[tajmone]

Well, it looks like in the end GitHub didn't carry out any auto-branch renaming, but left it up to end users whether to adopt the new default branch naming convention. So, it looks like we can just leave things as they are.