We love Git Flow. It's awesome to have a standard release process where everybody is using the same terminology and tooling. It's also great to have out-of-the-box answers to the same questions that get asked at the start of every project. For example:
"How are we going to develop features in isolation?"
"How are we going to separate release candidates from ongoing development?"
"How are we going to deal with hotfixes?"
Now it's enough to just say 'We use Git Flow', and everybody's on the same page.
Well, mostly. Whilst Git Flow is terrific for managing features and separating release candidates from ongoing development, things get a little hazier when it comes time to actually release to production. This is because of a mismatch between the way that Git Flow works and another practice that is common in large development projects: immutable build artifacts.
A while back Mark expressed interest to me in using git and git-svn for version control on his own machine, against a remote Subversion repository. However, when I followed up with him recently, he admitted that in the small amount of time he'd spent looking...
As I work, I like to be able to do very regular checkins to our Subversion server (ensuring the tests pass beforehand, of course). This gives me an easy fallback position if I make some change that causes test breakages. Sometimes it's just easier...