When to use git-flow and GitHub Flow

Some people ask how good git-flow matches with the practice of continuous integration. In 2011, Scott Chacon from GitHub Inc. wrote a post on exactly that: GitHub Flow.

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.