As others pointed out "master" is not always "production" or "release". In our work flow it is not.
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.
Any name that has to do with "production" is out for us -- it doesn't work.
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.
No it isn't. It assume you want to release from the default branch.
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).
Master makes far more sense as the default branch name. It is the "master" copy from which all other copies are made.
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.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.