Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense.
EDIT: Please not I am not suggesting that you not do feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.
And yes, you can branch and redo tags at any time. If you don't know this, you probably don't understand git's underlying model very well. Time to read up: http://www.google.com/search?q=explanation+of+git+internals
If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new branch from it? I could be wrong but I thought tags in git were basically just read-only and informational - can you start work from them?
If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.
I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.
(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)
You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into master and delete it:
git branch hotfix v1.2.3
git co hotfix
# do the fix
git tag v1.2.4
git co master
git merge hotfix
git branch -d hotfix
Commits are what's fixed. Branches are basically just mutable pointers to commits.
You can at any time go back to it as long as you know the SHA-1 identifier for the head commit you want. Because of this, there's little reason to keep temporary refs cluttering the ref namespace.
If you really want to keep references to everything, a "git attic" tool exists which allows you to move branch refs out from the main ref namespace into a normally invisible (ie. doesn't show up in git branch etc.) namespace.
If my edits grow to the point that I need to write tests or push to staging, I just checkout a feature branch before committing.
git checkout -b hotfix master
The master/develop model gives you a pointer to the latest release for free. The pointer is called master.
Without the 'extra' develop branch, you have to remember or lookup the name of the latest release if you want to make a hotfix, or keep an extra tag for it, in which case the two models are the same.
...you are "astounded" that some people never heard of some less-than-a-year-old add-on to a fashionable development tool.
tl;dr: good for teams, and housekeeping
Since time is my number one constraint right now, I'm taking advantage of every tool that makes me more productive. Yes, you can certainly implement the workflow with vanilla "git" but if you're going to follow the workflow model, why not use a tool that excels at that workflow? especially when said tool allows you to see what it's doing.
Worth reposting here in case anyone missed.
Here's a gist I created showing how an existing repo (although very basic) can be adapted to use git-flow - http://gist.github.com/538326
when in doubt, look at stuff in a repo's .git/ to find what you wanna fiddle with. unless of course you want to look at user wide config file at ~/.gitconfig
Then everyone just used git. It's interesting to see this dream come to a small amount of fruition.
I don't know that this could be added to it and not make it entirely more complicated.