> > Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on
> I don't see why this assertion would hold true.
The sole and entire purpose of Git Flow is to save up changes for a later release, and have humans come up with version numbers for them[1].
By saving up changes for later you are saying "my changes aren't ready for production, but I'm merging them to a shared branch anyway, and they will be tested later when a release branch if cut from develop".
Contrast that to Trunk-based Development, where master is the only long-lived branch, and it should always be stable and ready for production. That means changes (PRs) must be tested and ready for production[2] prior to being merged.
As you said, Git Flow would still have code review, CI, etc. But the mentality it fosters within a development team is the it is OK to merge things that aren't tested enough to say "this is ready to be deployed right now". After all, a release branch will be cut and tested.
The developers that make the changes are not the ones that cut the release branches. By the time someone cuts a release branch a week or two may have passed since the changes were made. The developers have moved on, and now someone needs to test the release branch (with a week or twos worth of changes) to make sure it is ready for production.
> Web applications, I think, are a special case where continuous change is the norm. Other applications do benefit from versioning. I certainly would be more wary about using Linux distros or git if they weren't versioned like they are now.
Certainly things that require releases shipped to end users with long term support of old release require versions. But a large percentage of the people on HN trying to adopt the Git Flow coolness are doing web applications. Also, I question how good Git Flow is at addressing the need for supporting multiple long term releases at once. But that isn't my area of expertise, so I won't rule it out.
[1] If you remove saving up changes you don't have anything left of Git Flow. Hotfix branches exist because changes that aren't ready for deployment have been merged to the develop branch, and normal "elease branches are cut from the develop branch. But duning the weeks of saving up changes you will need to release fixes for critical bugs, so Git Flow introduces hotfix branches then branch off master. If you aren't saving up changes for later, there is not need for hotfixes, because you would just deploy like normal. So by eliminating saving up changes you eliminate all the complexity of hotfix branches. release branches only exist for saving up changes, so they go away too. With them going away you no longer need a human to make up pretty version numbers. With all that gone there is nothing left of Git Flow.
[2] Ready for deployment, there still can be a short staging or canary process.
> I don't see why this assertion would hold true.
The sole and entire purpose of Git Flow is to save up changes for a later release, and have humans come up with version numbers for them[1].
By saving up changes for later you are saying "my changes aren't ready for production, but I'm merging them to a shared branch anyway, and they will be tested later when a release branch if cut from develop".
Contrast that to Trunk-based Development, where master is the only long-lived branch, and it should always be stable and ready for production. That means changes (PRs) must be tested and ready for production[2] prior to being merged.
As you said, Git Flow would still have code review, CI, etc. But the mentality it fosters within a development team is the it is OK to merge things that aren't tested enough to say "this is ready to be deployed right now". After all, a release branch will be cut and tested.
The developers that make the changes are not the ones that cut the release branches. By the time someone cuts a release branch a week or two may have passed since the changes were made. The developers have moved on, and now someone needs to test the release branch (with a week or twos worth of changes) to make sure it is ready for production.
> Web applications, I think, are a special case where continuous change is the norm. Other applications do benefit from versioning. I certainly would be more wary about using Linux distros or git if they weren't versioned like they are now.
Certainly things that require releases shipped to end users with long term support of old release require versions. But a large percentage of the people on HN trying to adopt the Git Flow coolness are doing web applications. Also, I question how good Git Flow is at addressing the need for supporting multiple long term releases at once. But that isn't my area of expertise, so I won't rule it out.
[1] If you remove saving up changes you don't have anything left of Git Flow. Hotfix branches exist because changes that aren't ready for deployment have been merged to the develop branch, and normal "elease branches are cut from the develop branch. But duning the weeks of saving up changes you will need to release fixes for critical bugs, so Git Flow introduces hotfix branches then branch off master. If you aren't saving up changes for later, there is not need for hotfixes, because you would just deploy like normal. So by eliminating saving up changes you eliminate all the complexity of hotfix branches. release branches only exist for saving up changes, so they go away too. With them going away you no longer need a human to make up pretty version numbers. With all that gone there is nothing left of Git Flow.
[2] Ready for deployment, there still can be a short staging or canary process.