With GitHub stripping out divisive terminology, what will developers need to know to make sure this transition is seamless?
From the office of "long overdue," another service is dropping the divisive "master" terminology from its technology. This time, it's GitHub and the new nomenclature will shift from "master" to "main." The reason for this change should be obvious, but for those that aren't sure, it's to rid the company of any holdover references to slavery and replace them with terms of inclusion that cannot be misconstrued.
This change across the tech landscape should have occurred long ago, but at least it's finally happening. Starting October 1, 2020 all "master branches" will be called "main branches."
For developers who have been knee-deep in Git and GitHub for years, this change will take some time to get used to. Even if you know the change is the right thing to do (spoiler alert: it is), your fingers have been typing git checkout master for years. Now, you're going to have to shift to git checkout main. "Git" used to it.
I would expect a lot of other technologies to follow this example, so devs will more than likely be, at some point, making similar changes to a number of the tools they use. But GitHub is different. GitHub is used by millions of developers, some of them working alone, but many of them working together. That means change is going to be global and project-wide.
SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)
What developers need to know about this GitHub change
Other than the change in terminology, how will this directly impact you? Let's take a look.
First, GitHub has already implemented the following changes:
GitHub.com links that contain the deleted branch name "master" are already redirecting to "main."
GitHub pages have been updated to deploy from any branch.
GitHub has added user, organization, and enterprise settings so developers can set the default branch name for all newly created repositories.
On October 1, 2020 newly created repositories will default to "main." Existing repositories will have the same default branch they currently have, and the change will not impact your existing repositories. Users, organizations, and enterprises can opt out of this change at the following locations:
Organization owners: https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults
Enterprise admins: https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges
By the end of the year, all existing repositories will be migrated to the new naming convention. This comes with a particular set of challenges, including:
Open pull requests must be targeted to the newly named branch;
draft releases must be targeted to the newly named branch; and
branch protection policies must be transferred to the newly named branch.
GitHub's intention is to ensure that, by the end of the year, all repositories will be able to seamlessly rename their default branch. That means when you rename a branch, GitHub will automatically retarget open pull requests and draft releases and move your branch protection policies. GitHub is also hoping to be able to redirect users who use either git fetch or git clone to move an old branch name to a new branch name.
You might think all of these changes should be a no-brainer and painless, but with over 40 million users, more than 100 million repositories, and at least 28 million of those repositories being public, this is a massive undertaking. One poorly planned move, and projects like the Linux kernel could find their code unreachable. Given that the whole of global enterprise depends on the Linux kernel, such an event could be disastrous, so GitHub doing this right is crucial.
How to migrate the default branch of your GitHub projects from master to main
As GitHub does its thing, the most important steps you can take is migrate the default branch of all your projects from "master" to "main"; if you don't, you'll be dependent on the tools GitHub creates to make this happen automatically. I'll show you what steps to take in a very generic sense (make sure you're working with the project in question).
Before you do anything, back up all of your work--you do not want to wind up losing your data from a branch rename--though you should always back up your work.
Move the master branch to main with the command:
git branch -m master main
Push the newly-named main branch to GitHub (assuming that is your remote repository) with the command:
git push -u origin main
Point HEAD to main with the command:
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
Now you need to set "main" as the default branch for your project on GitHub. To do that, log in to your GitHub account, open the repository for the project, and click Settings | Branches. In the left sidebar, click Branches and then select Main as your default from the drop-down. Click Update and, when prompted, click I Understand. Now, back at the terminal issue the command:
git push origin --delete master
That should take care of it.
More work to do regarding divisive tech terminology
I hope every sector of technology follows GitHub's lead and removes all divisive terminology. Projects like Go and Google's Android and Chrome have made concerted efforts to make such changes happen. Although Kubernetes uses terms like "node" and "replicas," as of June 2020, over 200 lines of Kubernetes code still contain references to "slave."
There's a lot of work to be done on this front, but technology is agile, and those responsible for creating it are forward-thinking. With one collective push, divisive terminology can be removed from the entire landscape.
How to become a developer: A cheat sheet (TechRepublic)
Telephone interview cheat sheet: Software developer (TechRepublic Premium)
Programming languages and developer career resources (TechRepublic on Flipboard)