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.
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.