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
Oldest comments (238)
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
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.
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.
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.
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 😆
😂
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
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 🌌
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
Super great post. I think this hits on all of it, and yeah the bitkeeper history is there, but also the existence of master/slave terminology in software in general sort of helps imply that even if git stopped explicitly saying “slave”.
Software needs to be flexible and evolve. It’s kind of the whole point.
Exactly, our goal should be to change norms to make people feel more welcomed and to have a more inclusive environment. This is the least we can do.
In terms of low-hanging fruit, I think it doesn't get any easier.
Might not be much, might not do a whole lot, it's certainly not the last thing we should do, but it's so easy and effortless that it should be a no-brainer.
I have never heard "slave" in discussions about source control ever; especially git. At least not until we decided we needed to change it.
I always thought of master as "law and gospel" in terms of this is the source of truth for the repository. Where the word originates or how it was used in what git was "built from" is not relevant, language changes over time.
The problem with lots of the suggestions, "unstable", "production", etc. They are all specific use cases for specific workflows. Master is not specific to anything but clearly states what the branch is for. Branching strategies in source control is an entire religion by itself.
I do think that "principle" as suggested in the OP is better... or "main", "root", "default"... but I still feel it is unnecessary to move away from a master branch. I won't enumerate all of the practical problems with moving away from master as many others already did a great job at that.
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.
I'd like to add my point of view, not in contrast to yours, but to further the debate.
First of all, I'm personally in favour of changing all software denominations such as "master/slave" and "blacklist/whitelist" to literally anything else that doesn't imply millions of people suffering.
I have a different opinion when we talk about Git though.
The word "master" by itself has a general meaning of "person (or, by extension, thing) with particular authority, knowledge or skills". This is paraphrasing Merriam-Webster.
A "master" can be a university degree, the original artifact from which copies are made, a master of kung-fu, a master of pottery, or an owner of slaves.
But this means that the specific connotation of "owner of slaves" is only there if the word "slave" is used in conjunction with the word "master" (or if used when talking of slavery).
In the case of Git, non-master branches are never referred to as "slaves". The concept in Git is entirely different. Yes, maybe the original inspiration came 16 years ago from BitKeeper using the master/slave terminology. Maybe it was just laziness. Maybe... we don't actually know. My feeling is that "master" was chosen to signify something different, as Git works with a different model (from my understanding). Additionally, even the link you provided isn't all that sure of its reconstruction (italic by me):
I've never in my life heard or read anything that used the master/slave metaphor to explain git.
My personal opinion is that it's too long of a stretch. I will not be changing the name of my Git branches for the time being (may change my mind in the future), but I will also avoid using the master/slave and black/white terminology in other fields or technologies where the reference to slavery is more explicit.
Just to be absolutely clear: I also don't see anything wrong in choosing to not name the main branch "master".
PS: In Italian, "hello" and "goodbye" are both translated to "ciao". "Ciao" has an interesting origin:
From Wikipedia:
I'm having a really difficult time understanding this line of reasoning. We, AT BEST, have a term that maybe originated from an oppressive term. And yet, we choose to keep it because: Well it's too much of a stretch, I'd rather keep it.
We, as developers, love to boast about naming, and how important it is. How is master an appropriate name to define this branch in git? Of all the definition of master I'm seeing, I don't see one that explains the naming of master. And I'll go ahead and say that it's too far of a stretch to justify it.
The truth is that this word implies the master/slave relationship. Maybe not for you, but the harm is real. Master/slave is still a used concept in technology. That's an oppressive term. By keeping master for no other reason than our little convenience, we expose people to this oppressive term, even when it is not explicit.
When harm can be done, we take the safest route and protect the most vulnerable.
I don't debate that master/slave is an oppressive term, but, honest question:
What do we do about "Master of Science"? What do we do about "master record"? What do we do about "master/apprentice"?
Where did I say I wanted to abolish the word master altogether?
You said:
I thought you meant the word master altogether, sorry if I misunderstood.
I should have been clearer indeed, that's my bad. That can happen when 2 people exchange in their non-native language 😄
I did mean master in the context of the git branch.
If it doesn't apply to "Master of Science" or other studies, why does it apply in the context of git? Where do we draw the line in this conversation?
Don't get me wrong, by all means, change it. The debate we are having is important to have I think.
I just don't really share the opinion, because I see technology as a non-political/-racial entity. IMHO politics should be kept out of technology as much as possible, but that is just me.
If I have to change hundreds of build-jobs, repo references and environments in all my clients projects, due to a political debate, that's where I actually draw the line and seriously have to ask for the ROI of this proposition.
Technology is not neutral, nor is it apolitical, but that's another debate.
The problem I have with master in the context of git is because it most likely comes from the terminology master/slave ( see the sources ). And technology as a whole has a history of using the oppressive master/slave in our domain.
At the end of the day, you do what you got to do, but building a more inclusive environment means we have to do the work. That's a small step, and a very easy one. Other steps are more uncomfortable and require more work 😉
I don't care about the other contexts of the words because I have not researched them. If their use is inappropriate, I will educate myself and stop using them.
Why is it not? A thing is just that, a thing. It has no opinion on anything. Why should we apply politics to a technology that is not political?
I'm sorry, but "most likely" is not definitely. I can find no word from Linus Torvalds about this. At this point, it is only speculation. I personally would speculate, it is the master branch, because it is the deployable branch and thereby holds authority over every other branch. That is the sole attribute a master has. Authority. Thereby the word master in context of git is apolitical and a sound choice.
But as I said, speculation, since there is no definite explanation by the developer of git.
Yet again I disagree. For a small project, yes, it's a small step and if people are more comfortable with it, go ahead, be my guest.
Now think about about something bigger. The git foundation joins in, replaces master with, I don't know, mainline maybe, and rolls that out in an update.
Hundreds of thousands of build-jobs and developer machines. Nuked into oblivion.
That is not a small step. That is something that can horribly go wrong and bomb whole companies if done wrong.
That is what I am getting at.
Political changes are never a small step. They always have implications and most of the time, pretty massive ones.
You should, because context matters in language.
There is a chance it comes from master/slave. That's all I need. Because software, even if you believe it is apolitical, is used by real people, and more often than not, against real people. And software is build by real people. And if we don't take active steps to make sure the environment developers work in are 200% inclusive, the software is faulty and harm is done to those who are the most vulnerable.
That's not a chance I willing to take anymore. We have done enough harm in the tech industry. That's on us to change our industry and make it better. And to me, when I see how much backlash there is on a six letters word, when black people have said for years that this nomenclature is problematic... Well, it scares me.
I am a white man. Things are quite okay for me in this industry. For a whole lot of people, it is as shitty as it gets. When I listen to the experiences of those people, it makes me realize that everything is political and for them, everything has to be fought for.
It seems like a lot work for you, alright then. But, as I said, this is the low-hanging fruit. It's the least expensive thing we can do. Yeah, it might uncomfortable for you, but it might start something life changing for a lot of minorities in our industry.
Alright, as for the first part, I absolutely agree. The drive to make Tech more inclusive is absolutely necessary. I fully support that.
But again, where do we draw the line?
Where do we stop? When is enough enough? Who defines we reached 200% inclusive?
If we are trying to build a utopia in technology, where everyone is, as you said "200% included", we are bound to fail, or endlessly spin in place.
Terms in one language more often than not mean something completely else in another. An example I was provided on a different site about this very same topic. Black in Spanish. Totally fine for spanish speakers, it implies a lot of bad things for a lot of other people.
Language is highly sensitive and contextual.
Here I am bound to disagree. The least expensive thing to do, is accept that technologies like git are tools, and tools are just that. Something you use. That's it.
I have never stated it to be an uncomfortable change. I have stated "due to a political debate, that's where I actually draw the line and seriously have to ask for the ROI of this proposition".
That is it.
I would ask you to stay civil and on topic please. There is no need to assume that the topic and change would be uncomfortable to me, because that way you implicitly brand me racist. Which I am proud to say, I am most definitely not. I am just practical and ask "why do you think this is necessary", since it obviously isn't for many people.
Yet again, context. Git is (I can think we can go as far as to claim it is proven), not made to hurt you or work against you in any way, so this argument doesn't apply here IMHO.
If you think git, or a term within it "might have a racist connotation", without any proof, all based on speculation, I have to and will question your line of thought as to why you think that is and why you assume people feel wronged by it.
It ends when our industry is welcoming and inclusive for everyone... We might fail. No excuse to not try. We might pick the wrong battles. This is a small one, it often start like that. But at least something happens
I also haven't seen any sort of serious argumentation for the pros and cons of making this change. The "reasoning" I've seen so far has been along the lines of
"master/slave" was once used to refer to evil things, therefore we shouldn't use the word "master" in Git. Nothing more than that, then we go straight into how to do something before even spelling out a convincing "why".I don't find that one-line argument convincing at all:
Hopefully the reasons above may help explain the update from the OP:
Thank you for your comment. I was feeling like my view on things was way off the mark.
Though you definitely described it much better and more sensible in your comment :D
You have my gratitude.
Thank you for spelling out the implications and bringing up the ROI point, which I've included in my, ahem, main, reply to this discussion.
I am honored to be a part of your well constructed reply!
Everything has a cost, most people seem to forget that. I don't even want to begin calculating how much this change would probably cost, even if it took only half an hour for the average project (which, let's be honest, is totally underestimated).
That's just the businessman in me.
Just don't quote me too much, I mostly blurt out my thoughts without the necessary filters for topics this sensitive. I would rather not drag you through the mud with me :D
Words do change meaning over time, and that's a very important point, but they also have different contexts, and the contexts in which master is and has been used over time are far greater in number than the master/slave context.
We have masters in many fields. sports and occupations. We use the word master in many situations, both social and technical, that have nothing to do with or have never had anything to do with the very narrow context of one person (master) owning another (the slave).
Add them up. How many uses of master are in use in language that have no relation whatsoever to the ownership of one person by another? I'm guessing it's 1000 to 1. Further, master is not derived from the master/slave context. Master exists independent of it.
And our minds should be able to operate independent of it, too. I find it wholly offensive that people are treated with such disdain that they must have their eyes protected from a combination of six letters that in the vast majority of contexts has nothing to do with master/slave.
One other point. This movement to simply remove words from the language is using the same strategy that government censors use to suppress free discussion. It's easier to simply eradicate words (or combinations of words) than it is to argue against the ideas they represent. The easy route is simply to ban. The more productive, and more moral route, is to challenge and discuss.
I respectfully disagree. If we had proof beyond reasonable doubt that the term originated from that context specifically, then I am all for it. But if it's only because "maybe" the term "master" in Git was originated from an oppressive term, then this change is definitely not the best way to move forward with the inclusion agenda that many people seem to have in the software community, and I believe that if the term did originate from something like that, it would have been changed long ago.
I think it is not our job to be offended by what we think other people should be offended by (the thing with the creator of Cyberpunk 2077 comes to mind). If people of a certain race are offended by something, then we should support them, but we should not assume the role of "being offended".
In short, if it ain't broke, don't fix it.
Interesting analysis. Agreed
"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.
I applaud your positive intent behind this.
Oftentimes in tech we consider our industry as "advanced" and yet we haven't done enough to be inclusive. And yet our history has been far from perfect in this regard.
Thank you! It's a very small step and the absolute minimum I can do. Hopefully, these little steps start a conversation and we will all learn and get better ❤️
Tech has done more than any other industry to be inclusive. Kids in Africa or India have $100 laptops where they can learn anything that we've put up online. Countless open-source software has enabled anyone, anywhere in the world, with absolutely no regard for race or ethnicity or anything like that, to do word processing and browse the Internet without paying anything to Microsoft. Crypto can liberate us from banks and government oppression (to talk about true oppression). Etc.
By being distributed over a medium where no names or faces are necessary, software is as inclusive as possible.
Yet changing a branch name is so hard?
The change is simple, but the implications are non-trivial and will cause far more pain than we think it may prevent.
Then maybe just do it on new repos going forward? I doubt I will go back and rename every repo I have going back ten years but I'm thinking for new projects why not? No one should be forced to do this but it's not a bad idea.
And BTW, I am 56 and was recording music back in the day on analog "master" tapes so I get what you mean by master tape or master pressing for vinyl but I have no problem using main or trunk as a branch either...
Let's say a person is new to open source, he/she searches google for tutorials about how he/she can contribute to open-source projects. All the tutorials will have the master mentioned. This will be really confusing for them. If they are new to open-source and computer science In particular, This will surely be a pushback for them.
Actually I would say if this is confusing for them they may want to look for another career... This is about as trivial as things will get for a developer. I'm sure in their Google search they will see a few results that discuss the renaming of branches for this reason. :)
Because nothing ever changes and we don't have any references to old and obsolete and failed-to-launch tech anywhere, amirite?
I remember when I first heard this terminology, I couldn't believe it was a thing in software!
I think renaming master to main makes the most sense, since that's how it is explained anyway.
"Master" is a term from the recording industry. I'm not a native English speaker so it 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, or having a "Masters of Science" or being a "master of the guitar" than slaves. Words change meaning over time.
Not in the computer industry.
Until the past decade or so, the "master/slave" terminology was alive and well and even the default meaning of "master" in this context, even if "slave" wasn't explicitly mentioned.
It was even engraved on hard drives until the early 2000s (until the early-mid 2000s, BIOS software would commonly look for bootloaders on any and all drives hooked up, unless jumpers on the physical drives were set to "master" and "slaves" -- or more accurately, the OS drive and data drives).
You can find the discussions had by several of the database organizations and adjacent groups about renaming the hub-and-spoke architecture from "master/slave" to something else.
They do, but in this case it's not a change of meaning. "Master" still means "overseer of subordinates" as one of its definitions.
The meaning, in this case, hasn't changed. The word is overloaded -- it has several definitions, not unlike overloaded methods in C# or Java (which is why the "Master of Science" thing is an absurd and bad-faith argument, because it's using a different definition of the word).
This overloading is actually an argument in favor of changing it, because there are many words to choose from that better describe the default branch and aren't overloaded -- both of which make the meaning more clear.
Why not just call it default? After all is the default branch.
Default works for me 😁
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.
zdnet.com/article/github-to-replac...
Added as an update in the article 😉 Thanks!
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