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

1. http://thedailywtf.com/Articles/Release-Management-Done-Righ...