Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
I recommend fully and completely against git-flow:
Research shows effective teams deploy multiple times a day, but git-flow discourages that by adding the “develop” branch, and by introducing feature branches and hot fixes. Those concepts are all performance-negative.
Science shows we should aim to have a single main branch that is always deployed, and just commit to that. Any branches you create must live for a maximum one day, preferably much shorter. Don’t worry about hotfixes either, just land changes to main branch. Instead featureflags become the way to control what and when things are released
git-flow is a tool and workflow that can look impressive, but it actually puts up more barriers and adds more deploy latency where science suggests we should aim for less.
The science I refer to is DORA and Accelerate book by Dr. Nicole Forsgren.
If you're already doing Continuous Release, I agree Gitflow probably isn't going to help your team.
However, not everyone is doing or can do Continuous Release, for any number of reasons. Those teams can often be helped by defining a standardized workflow that everyone follows. For instance, I work on a simulation for a government customer that has integrated test dates and milestones we have to follow. So we have a fielded build we have to support with hotfixes, a future build of that line for the next integrated test, and a future build that adds support for whole new assets that will require a lot of early development before it's ready to be deployed that we can't hold up the next build for. I've been trying to suggest that my project adopt Git Flow or a modified version of it because that's still WAY better than what we're doing right now, which involves lots of dev and release branch cross-merging instead of merging selectively and consciously from hotfix and feature branches.
As an aside, though, thank you for actually backing up your "research/science shows" statements with the source. I was going to accuse you of using weasel words there, but now I have a book to check out. :-)
That's your opinion...and its fine... everyone doesn't like the git-flow...
But forget about feature branch and hotfixes....even if you only have a develop branch...it keeps your deployed code more error and bug free...
As with all of these new or different techniques or approaches you need to begin by asking yourself: what problem am I trying to solve ?
If the way you work right now is fine and there is no problem really, then just stick with what you're doing and don't jump on the latest bandwagon because it's "hipster" or because everyone does it.
So is Gitflow good or not - as always, "it depends" ... but the moment someone offers me a "solution", then the first thing I ask: okay cool, but what was the problem again ?
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.
I recommend fully and completely against git-flow:
Research shows effective teams deploy multiple times a day, but git-flow discourages that by adding the “develop” branch, and by introducing feature branches and hot fixes. Those concepts are all performance-negative.
Science shows we should aim to have a single main branch that is always deployed, and just commit to that. Any branches you create must live for a maximum one day, preferably much shorter. Don’t worry about hotfixes either, just land changes to main branch. Instead featureflags become the way to control what and when things are released
git-flow is a tool and workflow that can look impressive, but it actually puts up more barriers and adds more deploy latency where science suggests we should aim for less.
The science I refer to is DORA and Accelerate book by Dr. Nicole Forsgren.
If you're already doing Continuous Release, I agree Gitflow probably isn't going to help your team.
However, not everyone is doing or can do Continuous Release, for any number of reasons. Those teams can often be helped by defining a standardized workflow that everyone follows. For instance, I work on a simulation for a government customer that has integrated test dates and milestones we have to follow. So we have a fielded build we have to support with hotfixes, a future build of that line for the next integrated test, and a future build that adds support for whole new assets that will require a lot of early development before it's ready to be deployed that we can't hold up the next build for. I've been trying to suggest that my project adopt Git Flow or a modified version of it because that's still WAY better than what we're doing right now, which involves lots of dev and release branch cross-merging instead of merging selectively and consciously from hotfix and feature branches.
As an aside, though, thank you for actually backing up your "research/science shows" statements with the source. I was going to accuse you of using weasel words there, but now I have a book to check out. :-)
That's your opinion...and its fine... everyone doesn't like the git-flow...
But forget about feature branch and hotfixes....even if you only have a develop branch...it keeps your deployed code more error and bug free...
Thanks a lot for your reply
I second that: georgestocker.com/2020/03/04/pleas...
As with all of these new or different techniques or approaches you need to begin by asking yourself: what problem am I trying to solve ?
If the way you work right now is fine and there is no problem really, then just stick with what you're doing and don't jump on the latest bandwagon because it's "hipster" or because everyone does it.
So is Gitflow good or not - as always, "it depends" ... but the moment someone offers me a "solution", then the first thing I ask: okay cool, but what was the problem again ?