Git Flow
git floh
A branching model with long-lived develop and release branches alongside feature branches.
Git Flow is a branching model created by Vincent Driessen in 2010. It defines a strict structure: a main branch for production code, a develop branch for ongoing work, feature branches for new development, release branches for release preparation, and hotfix branches for emergency production fixes.
For a time, Git Flow was the standard. It provided order in an era when teams struggled with version control workflows. The model made sense for packaged software with scheduled releases: version 2.0 is in development on develop, version 1.5 is being stabilized on a release branch, and version 1.4 runs in production on main.
Modern teams have largely moved away from Git Flow. The model adds ceremony (maintaining develop and release branches) that does not benefit teams doing continuous delivery. If you deploy multiple times per day, a release branch that lives for two weeks is overhead. GitHub Flow (branch off main, PR, merge) or trunk-based development is simpler for most web applications and SaaS products. Git Flow still has its place for software with formal release cycles, like mobile apps with app store review periods.
Examples
A mobile app team uses Git Flow for app store releases.
The team develops features on the develop branch. Two weeks before an app store submission, they create a release/2.5 branch. Only bug fixes go into the release branch. New features continue on develop for version 2.6. After testing and stabilization, release/2.5 merges into both main (tagged as v2.5) and develop (to include the bug fixes). The app store review takes 3 days.
A hotfix bypasses the release process.
A critical bug appears in production (v2.4). The developer creates a hotfix/payment-crash branch from main. The fix is one line: a null check before accessing a user's payment method. The hotfix merges into both main (tagged as v2.4.1) and develop. The production deploy happens within an hour. The current release branch (2.5) also cherry-picks the fix.
A SaaS team abandons Git Flow for GitHub Flow.
The team maintained develop, release, and main branches for two years. Developers constantly forgot which branch to base their work on. Merge conflicts between develop and release were a weekly pain. Release preparation took three days. They switch to GitHub Flow: branch from main, PR, merge, deploy. Release preparation drops to zero because every merge to main is a release.
In practice
Read more on the blog
Frequently asked questions
Is Git Flow still relevant?
For specific use cases, yes. Mobile apps with app store review periods, embedded software with hardware release cycles, and enterprise products with contractual release schedules benefit from Git Flow's structured release process. For SaaS products and web applications that deploy continuously, Git Flow adds unnecessary overhead. Even Vincent Driessen added a note to his original post saying teams doing continuous delivery should use simpler workflows.
What is the difference between Git Flow and GitHub Flow?
Git Flow has five branch types: main, develop, feature, release, and hotfix. GitHub Flow has two: main and feature branches. In GitHub Flow, you branch from main, make changes, open a PR, and merge back to main. There is no develop branch, no release branch. Every merge to main is a potential release. GitHub Flow is simpler, faster, and better suited for continuous deployment. Git Flow is more structured and better for scheduled releases.
Related terms
A separate branch in version control where a developer builds a new feature before merging it to main.
A branching strategy where developers commit directly to main (trunk) or use very short-lived branches.
A parallel version of the code that lets developers work on changes without affecting the main codebase.
Combining code changes from one branch into another, integrating the work.
The process of releasing code to servers where users can access it.

Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.