For the last few weeks we switched from git-flow to GitHub Flow - on GitHub as well as on our gitblit-Server (needs gitblit tickets, v1.4+).
Working both with GitHub Flow vs. git-flow taught us a lot. Well, the direct ticket integration alone is a big win compared to manually keeping commits and tickets consistent, i.e. basically pasting a lot of links in each of them. Apart of that, without surprise we came to the same conclusions as Scott Chacon, i.e.:
- For continuous deployment projects, github flow is way more effective because you can have dozens of commits each day going directly into production. The many branch transitions required in git-flow quickly become a bottleneck and lose their worth as quality gates. The similar holds for small projects or simple software components where git-flow is just too big a framework.
- For products with greater release cycles (weeks or months) git-flow makes sense. Example scenarios are concurring milestones (hotfix from production vs. feature for next version) or just bigger quality gates, i.e. a commit should not or can not be directly deployed to production.