Over time, I have come to feel this git workflow is more of an attempt to coerce git into a workflow that is familiar to users coming from subversion, rather than learning and understanding git's strengths. A corollary problems is that it mixes development workflow with release management - two disparate concerns that should be handled separately.
After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in feature branches, based on either the most recent production tag or the master branch, depending on if it is a hotfix or if it is new development work. A lot of people do not seem to understand you can just checkout a tag, so you do not need to keep a number of hotfix branches around for in-house repositories.
Now, it would be nice to develop a better tagging strategy for rolling updates to a web application, but, for the time being, simply using a stage and production tag work well enough. This is certainly suboptimal and can cause problems, and I cannot recommend doing so. Instead, use production and stage tags with either sane version numbers or simple timestamps. It would be best to only promote from staging to production, but that is not exactly necessary. Most of my thoughts on the release management side of things comes from Alex at The Daily WTF [1].
I'm not the parent, but I find the nvie.com branching workflow a little complicated.
My experience lies a little bit with the kernel workflow, but heavily with the Openstack workflow, which has large codebases as well.
Both workflows differ from the nvie.com workflow by not needing a 'develop' branch and as a result, needing less merges.
Both Openstack and the Linux kernel use 'master' for development. In the kernel case, changes are reasonably well tested and vetted before they hit 'master' by the use of maintainer branches.
In Openstack, all changes get gated through a variety of unit, functional and integration tests, so they are reasonably well tested as well.
AFAICT, feature and release branches work the same in all three workflows.
I guess both Openstack and the Linux kernel care less about hotfixes since neither run production systems, only their customers do.
In my capacity running a production Openstack system, we apply hotfixes to our release branch and then deploy it from there.
I guess I just really dislike all of the merging that happens in the nvie.com workflow and the extra 'develop' branch as a result. It seems unnecessarily complicated.
I am working on average size web applications, which simplifies things greatly, but I do not think your characterization of kernel development is correct.
The official kernel mirror on github[1] does not have any of these extraneous branches, and, unsurprisingly, makes good use of the tagging ability built into git.
In fact, the kernel developers prefer[2,3] that feature branches are always based on a known working state if possible, rather than some arbitrarily moving branch, be it called master or develop. That said, the master branch of the linux kernel is, by no means, relegated to only having merge commits from feature branches that correspond to releases.
After a few release cycles, we decided to switch back to simple feature branches with a master that is always deployable.. modeled after GitHub's workflow:
http://scottchacon.com/2011/08/31/github-flow.html
We found GitFlow's benefits weren't enough to compensate for the added complexity and subpar GitHub integration.
I did just enter a shop where git is new to a lot of people. Kind of blew my mind but I've been in startup land for years and just came back to enterprise development.
After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in feature branches, based on either the most recent production tag or the master branch, depending on if it is a hotfix or if it is new development work. A lot of people do not seem to understand you can just checkout a tag, so you do not need to keep a number of hotfix branches around for in-house repositories.
Now, it would be nice to develop a better tagging strategy for rolling updates to a web application, but, for the time being, simply using a stage and production tag work well enough. This is certainly suboptimal and can cause problems, and I cannot recommend doing so. Instead, use production and stage tags with either sane version numbers or simple timestamps. It would be best to only promote from staging to production, but that is not exactly necessary. Most of my thoughts on the release management side of things comes from Alex at The Daily WTF [1].
1. http://thedailywtf.com/Articles/Release-Management-Done-Righ...