After getting hired on my current team my first course of action was to move from gitflow to github flow.
http://scottchacon.com/2011/08/31/github-flow.html
If you break projects into small iterations made up of independent effort and continuously integrate feature branches, you should be able to get away with few long-living branches, and you can rebase the ones that you do have from their upstreams frequently enough that they don't get to where you need to expend lots of merge effort when they're ready to ship.
With gitflow, we were eating lots of effort merging caused by hotfixes. Hotfixes would have to get merged into every branch lest you risk regressing them, no rebasing of development on master (for good reason when there's so many people merging into it), people would forget - and the git extension would only do some of the required merges, so before I showed up the team had a spider's web of merges where changes would get lost and hotfixes regress.
If you must have a stable and active branches, gitflow is fine, but make sure everyone really understands git and what they are doing with it (using the gitflow extension prevents this in my experience), do your due diligence and avoid changes on the stable branch like the plague.