Master/slave denomination
The master/slave denomination is a common one in technology. Master/slave is an oppressive metaphor referring to the practice of slavery. These metaphors are inappropriate when describing concepts in technology. They are also inaccurate. Using these metaphors takes away the history of slavery and put it into a context where it does not belong.
UPDATE: People seem to push back on this, for whatever reason... Git's master is historically tied to master/slave. It got the name from BitKeeper. Source here
UPDATE 2: Github is looking to replace the master word
UPDATE 3: This blew up. I'll have to reflect on many things about this subject. I still think that the word should go away from git. Period. However, I was not the right person to brought that kind of topic on the table. I have done harm in the process and I apologize for that. I'm leaving this article up for accountability. Learning to shut up listening and prioritize Black voices is something I will work on.
Words matter. The words we use to define concepts have a lot of importance, even in our tech environment. Git is one of those environments where the word master is still used. But, it's not that complicated to take it away. We have to do two things:
- Replacing the word on existing branches, both locally and remotely
- Modify your git configuration to not use the word master when running
git init
Let's start with the first point.
Replacing master from your existing projects
First off, we have to change our master branch locally.
I have here a project with a master branch. I'm running git branch -m master principal to rename my master branch into the principal one. This command keeps the history of the branch, so you won't lose anything!
Note: I chose to rename the branch as principal. You can choose another name if you wish. It has to make sense for you and your team.
Running git push -u origin principal updates the remote repository by adding the principal branch. The -u flag also sets the upstream.
Change the default branch on Github
Now, I also need to change the default branch on Github. In your repository page, click on the Settings tab, then branches on the left menu. You can update the default branch here:
And you are done! If you run git log inside the principal branch, you will see that the history is intact!
We started on origin/master and it properly show that we are on principal now!
Updating local clones
What if someone has a local clone of this repository, how would they correctly update their clone?
This tweet explains you how:
xUnit.net@xunit
@bradwilson Quick instructions for how to fix up the name change from your local clones:
$ git checkout master
$ git branch -m master main
$ git fetch
$ git branch --unset-upstream
$ git branch -u origin/main
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main06:36 AM - 08 Jun 2020
0
7
$ git checkout master
$ git branch -m master principal
$ git fetch
$ git branch --unset-upstream
$ git branch -u origin/principal
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/principal
Note that the tweet uses the word main to replace master. I'm using principal. Just replace it in the commands with the name you chose.
What these commands do:
- Go to the master branch
- Rename the branch to principal
- Get the latest changes from the server
- --unset-upstream removes the link to origin/master
- -u origin/principal creates the link to principal
- Updates the default branch
Git init
When you run git init, the default branch is master. There are two ways to change that:
Using an alias
You can set up an alias that would run git init while having a other default branch name:
git config --global alias.new '!git init && git symbolic-ref HEAD refs/heads/principal'
Running the above command would allow you to use git new and it would have the principal branch as its default.
You can modify this command of course. Notice the alias.new, this can be change to alias.initialization for example, or whatever command you would like to make. Of course, you can also modify the principal name to fit your needs.
Modifying your git config
We can configure our git to change the default branch.
Find the configuration file of your git. It should be either in
~/.config/git/configor~/.gitconfig.Inside this file, add the following lines:
[init]
templateDir = ~/.config/git/template/
Now, inside ~/.config/git/template ( you may have to first run mkdir ~/.config/git/template to create it), create a HEAD file and add this line, plus a line break.
ref: refs/heads/principal
When you run git init, the whole contents of the templateDir is copied into .git.
You can now run git init and you will have the branch principal as its default!
Of course, you can change principal to another name if you wish.
Alternative names
I've chosen to use the word principal to replace master here. Here are other words you can use:
- main
- primary
- leader
- active
- parent
Just don't use master...
Have fun ❤️
Do no harm.
Sources
Top comments (238)
There are so many problems with that statement that what I initially wrote as a quick response has turned into a longer post. Read it at 8 problems with replacing "master" in Git.
This comment is only kept for historical purposes.
First off...
1. There's no "slave" in Git.
Maybe RAID disk arrays would have this problem, but not git. So there's no "master/slave" metaphor in Git to speak of.
2. Words change meanings over time
"Master" is a term used the recording industry, or to talk about skill ("Master of Science", "Kung Fu Master" etc.). I'm not a native English speaker so "master" was strange to me too, but in American English "master" has been far more commonly used in the past 50 years to talk about vinyl records and CDs and degrees and expertise, than slavery. As someone else said,
3. Nothing is oppressive by itself
People choose meanings. Epictetus famously said this of insults (and "master" is far from an insult, but to illustrate the point):
4. Who does the word "master" really offend?
Has anyone ever complained of being oppressed when they saw a "master" branch in a Git repo? From what I've seen so far, black developers haven't felt offended by this word.
5. What are the downsides of this rename?
When making a decision of this scale, that invalidates 15 years of scripts and CI processes and Git tutorials using the word "master", it would help to see its ROI. If nobody is actually choosing to be offended by this word, then all we're doing is wasting time changing a perfectly working process just to virtue-signal that we're "woke", while annoying far more people in the process and wasting their time when "master" won't work and "principal" will break things. Do consider that the vast majority of developers have nothing to do with oppression, and have never intended to oppress anyone.
6. Is this purely a PR move?
But hey, by being outspoken against "master", brands benefit from stoking the fires of racial conflict to elevate themselves in the eyes of consumers. Sony, an organization using cobalt mined by literal black slaves, including children, is in favor of BLM. GitHub renaming a branch is a cheap PR stunt when they could do far more meaningful things, like not working with the ICE:
...or not banning Iranian developers, suggesting they use GitHub to develop nuclear weapons.
7. What shall we rename next?
Slaves were hanged from branches at some point, should the word "branch" be changed? How about the Lighthouse web speed auditing tool? Light is usually white... How about the Invictus poem? Let's ban it!
8. Is this humiliating to black developers?
Last, and worst, by removing the word "master" blindly, we're uncritically reproducing a narrative that diminishes black agency in favor of a white-centric explanation. We're making the assumption that a black developer can't take the word "master" as simply a label and nothing more. Don't you think black developers may find that assumption humiliating?
I totally agree with your points, I think these kind of changes are only making things worse than they were before, I never heard anyone who ever complained about this term.
I am a developer and I am black(not speaking for anyone else of color) yet I have never felt offended by a word I see in a software that I use or don't use, I think there are far much better things we can do as a community if we agree to live with our different cultures.
Well I'm not changing! Master stays! Period!
I really expected this to be a joke. But horrifiedly it seems to be real to some people. This mass hysteria is very strange to me. People really are that stupid.
Lets destroy all history and never learn anything from the past. Yeah
Anyone ever checked the skin color of someone doing a pull request before looking at the code?
It's cray.
"Words matter. The words we use to define concepts have a lot of importance"
Yep, they do. Context also matters. Pretending you don't know a word doesn't make whatever connotations may apply to said word (out of context) magically disappear. Should we also stop using the word "integrated" in IDE, since it's also a reminder if you take it entirely out of context? How about "dark" color schemes and "race" conditions? On other "trigger" words, as mentioned in other comments, are you also going to insist on renaming FAT (file allocation table)? How about "smart TVs", since the name must surely be offensive to those who got a low SAT score, or even "SAT" for paraplegics who find its association with "stood" offensive? How about the handiman's footstool? Stool means poop in the same lack-of-context you're applying to Git's branches. Poop is gross so we shouldn't call a tool a piece of poop. For that matter, we're all using tools here, and "tool" is sometimes used as an insult, so we obviously need a new word for the things we're using every day to do our jobs.
The rabbit-hole of stereotypical SJW bullshit always goes deeper. Language has context, and that matters.
If we visualize Git as a flow of branches from a single point in history, then names like default and main are more accurate. I would even use origin, but it's usually reserved for Git remotes when forking repositories. For myself, a branch called master would tell that branch has total control over other branches which is not the case with Git.
The push back in this issue is very typical human behaviour visible in many discussions in our society. When someone declares that eating red meat is bad for you, there usually is at least one stating how they will grow their meat consumption just to arouse reaction and potentially ease their insecurity.
Let's strive for a more inclusive future in tech and make software that is painless to evolve as time goes by.
When I was first learning git I found master to be wholly unhelpful in helping me grasp the concepts.
I also feel like when I was getting familiar with continuous integration I again would have gripped things better if explicit and purposeful main and secondary branch naming were a thing instead of the master terminology.
Why not just call it default? After all is the default branch.
In our organization,
developis the default branch. I like the suggestion above of usingproductionorrelease.As others pointed out "master" is not always "production" or "release". In our work flow it is not. That feels like the main practical issue. We can't all agree on a branching strategy and everyone deploys differently. Code has to move differently. Any name that has to do with "production" is out for us -- it doesn't work.
That's an argument in favor of "production" being the name of the default branch, because then it forces you to be mindful about setting up your workflow and using the intended process from the get-go (even if that setup ultimately becomes automated). Something rather generic and non-descriptive like "master" allows for people to fall into bad habits during the beginning of a new project, even when the process dictates otherwise.
What's your workflow look like?
No it isn't. It assume you want to release from the default branch. We don't and I am sure there are many others that do not either. There is no single workflow that is correct for everyone. I am very much against anything in a tool that forces a workflow. As soon as you do that you will find people needing to work against that workflow. It creates unnecessary friction. Master makes far more sense as the default branch name. It is the "master" copy from which all other copies are made. Think recording master for film -- less of a thing since we are basically all digital now but that isn't the point.
As far as what we do... We have branches for each environment; Dev, Beta, Demo, and Release (Production). Each environment has its own web, file, and database servers. A typical change workflow goes like this (feel free to substitute merge and pull request as you like -- they are effectively the same in terms of the end result).
A feature branch is made from master -> development work done -> feature is merged to beta for testing -> merged to demo for external UAT
From here once QA and UAT are done we have a group that reviews items pending release. We sometimes have conflicting timing needs or things that are interdependent. We have a lot of different things going on so not everything that finishes UAT is released just because it has passed. The code makes its way into into master when it is approved for release. Once approved the feature is merged into master, call it a release candidate if you want.
From there a merge is done from master to release. Builds are connected with each environment branch to deploy as needed. Our releases happen once a week at the same time. We need to maintain a link to what is in production in case we need to hot fix. It is rare but it does happen.
Could we do it differently? Probably. Are there better ways? Probably. Is this way wrong? I don't believe so. We have had a very good success rate with it. We aren't containerized. We have heavy environments. It is just the way it is. So we are managing what we have that gives us speed of process with some security / safety.
I would LOVE to be in a fully CD/CI pipeline. We just aren't there yet. I don't think I would change much about the process other than automating a lot of the steps though. I would still want unique branches by environment. It just makes things clean, clear, and easy. What is in production? Look at the release branch. It'll tell you.
I don't care that much if the name is changed (although to me there are far more issues than folks are willing to openly discuss with renaming the default branch). Trunk is better as it has a similar meaning. But git hates svn... I am very much against anything that would imply a workflow.
Okay, it seems my attempt to describe what I'm talking about more succinctly failed.
Let me retry with the full text that I posted elsewhere:
In my opinion, naming the default branch "prod" (or some variation) is actually a fantastic idea almost regardless of workflow. Here's why:
In every workflow, there's a branch, somewhere, that pushes to production. Whether that's the default or not and what exactly it's named isn't particularly relevant in the context of git (branches can always be changed). It's still the one that gets pushed to the production server or pulled by the pipeline to build the production result in some fashion. This makes it explicitly clear that this branch is the production one.
Naming the default branch "prod" sets up that expectation and discourages directly changing the code on that branch from the get-go (something I know I'm guilty of). In other words, it forces us to be mindful of what we're doing, even early in the project, where habits are most likely to be formed and ingrained, but workflows and processes are most likely to be super loose. We start with the habits we want in the long run, instead of allowing bad habits and then having to unlearn them later.
In workflows where the default branch isn't supposed to be "prod," it forces that split immediately (again, avoiding the fast-and-loose tendency that can happen early in a project), by forcing a new branch to be created to become the new default branch.
The beauty, too, is that most of this can be automated with aliases if you want the automation. Then you get the git scaffolding your project needs from the beginning, and you've still gone through the process of making thoughtful decisions about it (or, you made the deliberate effort to not be thoughtful and mindful about how you set up your git repository).
You rail against assuming workflow and yet you're doing exactly that here. I've worked with several workflows where master very much isn't the "master copy from which all other copies are made." In fact, I've used workflows where "master" was not branched from at all after the initial workflow setup. (My static sites use "master" for their generated output. That branch doesn't even have history, because the pipeline nukes it with each update.)
But here's the thing: no matter what the default branch is named, git doesn't assume workflow. The default branch only exists because it needs a branch to work with. Git itself doesn't even follow your "master branch is master copy" paradigm except in the loosest of senses (because it needs a branch to start with), because it doesn't care what branch you branch from (or merge into). It's only when you get into the broader ecosystem tools like Github that you really start seeing this paradigm, at which point, it's fully configurable.
Default works for me 😁
Nicely done! I've been using "unstable" for a while now, just due to my sheer love of Redis (this is their main branch name) - - - AND the fact that I have a healthy skepticism about whether any given commit I make will actually work 😉
Pulling in fewer cultural connotations is bonus! ✌️
Haha, I've never heard of the unstable branch before, but that's a nice touch. If my imposter syndrome is kicking in that day, I'm not sure I would have enough courage to push to an unstable branch 😆
Nice to know I'm not the only one affected by imposter syndrome. haha!
No no no. I belong precisely because I ship errors 😉 mistakes are fun and universal 🌌
Is it implying that the HEAD of the default branch is the
unstablerelease and Tagged versions arestablereleases?Yeah, and they also hang onto release branches in addition to the tags
😂
This is confusing since to me "master" = "release" branch and the unstable branch is "develop". Of course I have about 20 repos and like 18 of them have no develop branch. So changing "master" to "unstable" and having no releases is more accurate for me! Using unstable would be a warning to everyone.
I think I'm going to name mine 'disturbed' and let THAT be a warning to everyone. 🤣
Haha 🏆 💯 🌟
Yeah I think Redis specifically likes to just discourage people treating their default branch as the source of truth. So I think that can be helpful in some legitimate measure. I've worked on teams where it's like, "master is sacred". Also valid, just depends on the local attitude
As far as I know, the issue is not with the word
masterbut with the wordslave. I'm not sure why you see git'smasteras the kind of master/slave relationship.To me, git's
masteris more of amaster/copy:Git's master is historically tied to master/slave. It got the name from BitKeeper.
Source here
Not quite. That was an interpretation, based on quite a lot of inference ('probably'). On the other hand, the guy who actually came up with the term says he meant it as in 'master copy': twitter.com/xpasky/status/12722807...
FWIW he also suggests that the BitKeeper history might also be valid.
Given the fact that I don't remember why I called a thing that thing 6 months later, wouldn't surprise me if that were the case. It's also possible that both were the case:
master, the word, came from BitKeeper, and he also learned that it meant something else.Yes, you are right. I later learned that the git team were thinking and using 'master/slave' terminology for repos around that time.
Fair enough. If you look at bitkeeper's documentation though, it refers to master as the master repository. In git, all repos are equally important, it is hard to see when we normally use a server (eg. github) as the source of truth. But in reality all repos are their own master. If anything git freed all the slaves, hehe.
I hear your point. But the master/slave denomination is still quite common is technology. Even if it is rarer these days. The history is there and even if the meaning has changed or time has passed or whatever, if there is a slight chance that this will be interpreted as master/slave ( like it is today ), it should go away.
UPDATE my comment grew into a proper post, 8 problems with replacing "master" in Git.
The comment below is only kept for historical purposes. PS: congrats to the OP for taking more time to think about this issue and keeping their post for accountability.
Why exactly should it go away? Because one sensitive soul out there doesn't have a bit of self-control and chooses an interpretation you have no control over?
Did you mean to oppress anyone when you simply used a word that had become standard?
Words have multiple meanings. "Drug" can get you in jail, or save your life. Should you never use "drug" again because a cop might interpret "I need a drug for pain" as you seeking fentanyl, not aspirin?
There's always going to be someone offended or triggered by anything. Choosing an interpretation of a word with multiple meanings is just that, a choice.
To me, "master" comes from the records industry, where you had a master record/CD and made copies. I don't see why I should mess up all my git workflow and scripts for the purely theoretical slavery interpretation of the word by nobody who will ever use my private repo, and why all git tutorials and articles should become invalid because "master" is now demonized.
Has anyone ever actually complained about this word for git branches?
Yes
Who? Other than you.
But who knew that that was the origin? I remember the days of The appallingly-named master & slave device controllers, but had no idea that the same terminology was originally in git.
The problem here is those originals are not meant to be changed; a new version can be made but it never really replaces the master. And there should only ever be 1 master copy. thus implies this branch should never be touched. But that is rarely the use case for the primary branch.
I like main for the primary branch's name; it doesn't imply anything more than "this is the primary source to use".
You can create new masters out of old masters. Which is exactly what git does. Same for other types. You grab all the masters from recording a movie and produce a master for the actual movie. You edit it for the dvd version and you get the master for the dvd version...
The fact that it gets updated doesn't make it let of a master. Deployments get copied from there and can't (shouldn't) modify the code. And it is at any given time the source of truth for your project.
Having said that, I don't really mind how we call it. I'm not against changing the name. It is just a convention. If it was for me, we can call it
potato😅I'm aware that you can do that; my point is that the terminology doesn't imply that for a lot of people, myself included.
When I think of a "master" copy, I think of the original manuscripts for something like the Iliad. We're not meant to change that copy because it serves as the source of truth for the Iliad story. Once you change it you have a new copy with a new "master" version that doesn't replace the old (unless it's a verbatim copy). In git though, that new version becomes the master copy.
But I'm glad you are open to change though, I actually don't see the full association with master/slave either tbh. I just don't think the name made much sense to begin with, thus if it also makes some people uncomfortable then there isn't much of a reason to keep it. 🤷🏻♀️
I think the misconception comes from interpreting master as a single entity. The difference with the master for a book is that copies are meant to be the same book. If your book is a modified copy of the Iliad, it is a master for its own version of the Iliad. What your describe in git is not copying, is creating new Iliads. We add more stuff and create a new master for others to make copies of. Which is the most recent
master.The reason to keep
masteris cost mainly. Cost of changing all the tools, hours lost trying to figure out why some script doesn't work or why some tutorial doesn't make sense. EVERYTHING has a cost. Even keeping it has a cost, a different kind though. Is it worth it? I don't really know. This article is the first time I've encountered this concern, without digging a bit more I don't know if it is a shared concerned or just someone creating a problem from nothing... 🤷♂️To reiterate, I'm not against the change. I just think it is good to understand NOTHING is free.
"production" also sounds clearer..
So you could have
development -> staging -> production
Except master isn't always production. Not every project has a production.
It's really ironic a white, French man decided his was the voice to push for this.
You don't need to agree with him..
But I'm more fascinated by the vehemence with which some people find it necessary to refute him.
If you don't like it.. fine.. don't do it.
It is important to refute him because it's ignorant and token and accomplishes nothing.
On a deep thinking, there is indeed another way.
Stop using English for everything. (and stop being anglio-centric.) English is mostly widely-used by people who, in the past, tried colonialism and tried to find "helpers" around the world, anyway.
What alternative do you propose? What language would be widely understood and has never been used by an oppressive culture?
Please, let's not get ridiculous. There's no feasible alternative to English. I've been writing about this since 2008. English unites us, regardless of native tongue, ethnicity, skin color etc.
It's a terrible argument to say
By the same logic, we should stop using computers because computers were used to perpetrate billion-dollar hacks.
Spot on. You could even expand further on it.
Don't forget that IBM provided the logistic systems that were used to run Hitler's concentration camps.
Swiped a Master-card recently when shopping? How about Visa, thinking about borders here...or American Express, which could be argued makes references to the US railroad system, built in part by slave labor. Where should we stop?
I think French and Esperanto have tried at some point, but failed.
The only alternative I think is possible is, Simple English. That is, English with limited words. However, there would still be things like black, white, and main.
It is hard to be politically correct and please everyone.
You suggest French as an alternative to English, as if they’ve been somehow less colonial and oppressive throughout the ages?
Simple English isn’t a language. We’re programmers; our very work involves a lot of specialized terminology that wouldn’t come close to meeting the requirements of a “simple” English.
(And what’s wrong with “main”?)
OK, I've never thought about this before. You just blew my mind...
One of the things we never discuss is the language we use...
Wow. As a French speaker, I can't believe I never questioned once that... Thank you ❤️
English is the most spoken language in the world, and the 3rd in the number of native speakers. Computers, and most modern technology is derived from inventions created by English speakers, mostly native ones. That is not going to change any time soon.
I assumed he was just being funny with such a ridiculous suggestion.
I don't think he got the memo, lol.
World class troll. Thanks for this 🤣
That wasn't my intention, but it did indeed go further than I thought.
I assume you're joking in which case: Classic! I love it.
Let's take this to its logical extreme where people who never owned a slave in their life are not able to use the only language they know how to speak: English, because some of their distant ancestors owned slaves. What about black people whose distant ancestors were actually slaves but only know how to speak English? Should they also stop using English?
The concept reaches ridiculously humorous outcomes in mere milliseconds so I think it's worth further exploration.
Maybe we should use French, Dutch, Portugese or Spanish... dang! They were all colonizers also...
A crazy thing I heard of recently is that in the 1600s the English enslaved hundreds of thousands of Irish (white) people also - sending them to the Carribean. They were actually worth only about 1/5th the value of an African slave for some reason - maybe they blistered up with sunburn and were in constant pain in the hot, sunny climate that they their skin had not evolved to deal with.
It was enlightening to realize that some white people were also slaves to other white people.
Ah, it's a strange, mixed up world we live in...
Not using English for everything is going to be impossible. English is the language of business and like it or not connects the world. That doesn't mean that other languages are not important, valid, for viable; but it will be next to impossible to shift the entire world to a different language.
Ok, if you want it, then do it. No harm.
But you have to see that all the projects are being written and given support in english because from the languages that are spoken by the majority, is the easiest of them (Spanish and Chinese are not as easy as english).
Yes, we could use Esperanto, but not everyone knows it.
Think as a developer: how many of your libraries/frameworks you'll have to replace and refactor if the Original Developer decides to write the whole resource in their native language... And also, how many will stop being available because of this?
But as I said in the beginnning: you may do it to your own code, but you'll have serious issues when trying to look for some support.
Or, as Jason Tibbetts stated: what solution do you propose? This is causing more troubles, rather than giving a solution.
The Git Development Community is working to at least make the name of the main branch easily configurable, so in not so far future having "main" or "trunk" branch instead of current default of "master" from git-init / git-clone would be much easier.
Flexibility like this is critical for the health of software development in general. IMO this is a good stress test on software maintainability in general.
What's wrong with it now?
As far as I remember, changing the default branch would be able to be done with command line parameter or a configuration variable
or
Please tell me you're being facetious...
Why would I be? It's as easy as specifying the branch name in your checkout command to change what your default is.
Because you asked what was wrong with a 7-step init process, in response to someone mentioning that the git developers are working on making it a configuration option.
It's not a seven-step process, though, that was just a complete example for illustration. It's as simple as:
Or, we can just do
once, and never have to worry about it again.
We also don't have to worry about alias syntax, which is terminal-type-dependent, and can include it in provisioning/dotfiles repos and it works regardless of the person's system. :)
This option was, as far as I know, not available at the time of writing the blog post in question, and possibly also when I was writing my comment.
It wasn't available yet (though it was already in the pipeline). I was responding to Max, whose response suggested that the addition wasn't necessary and the then-current workflow was sufficient.
Even if the latest release (with this config option) hadn't been out when I responded with the config, I still would have argued in favor of having it as a config option, with the same arguments of being able to set it once and not have to worry about terminal aliases, etc.
Do as you please, this isn't Facebook. Is a friendly community. Sarcasm on a touchy subject isn't going to get you anywhere. About 90% of your comments are immature as hell, so therefore I rest my case.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more