GitFlow

framework · computer science · organizing-schema

Driessen's branching model with develop, feature, release, and hotfix branches.

GitFlow was articulated by Vincent Driessen in his 2010 blog post 'A successful Git branching model' (nvie.com), prescribing a branching strategy with two persistent branches (master for production-ready code, develop for ongoing integration) and three categories of supporting branches (feature branches for new development, release branches for preparing releases, and hotfix branches for emergency production fixes). The model was widely adopted in the early 2010s as Git replaced Subversion in many organizations and provided structure for teams unfamiliar with distributed version control. Driessen himself published a 2020 update noting that GitFlow was designed for software with explicit version-numbered releases (downloadable, packaged software) and that for continuously-deployed web applications, simpler flows like trunk-based development with feature flags are more appropriate. GitFlow remains in use for software with formal versioned releases (libraries, packaged software, embedded systems, mobile apps with app-store release processes), but for web applications has been largely superseded by trunk-based development in modern engineering organizations.

Originators

Vincent Driessen high

Year / Decade

2010 (Driessen blog post); 2020 (Driessen update note) high

Primary sources

Driessen, V. (2010). 'A successful Git branching model' (nvie.com), Driessen, V. (2020). 'Note of reflection' update on the original post high

Core components

Two persistent branches: master (production), develop (integration)
Three supporting branch types: feature/* (new development), release/* (release preparation), hotfix/* (emergency fixes)
Branch lifecycle conventions
Tag-based version marking on master
git-flow command-line tool
Driessen's 2020 retrospective noting limited fit for continuously-deployed web apps

Primary use case

Software with explicit version-numbered releases: libraries, packaged software, embedded systems, mobile apps with app-store release processes; teams transitioning from older version-control systems where the structured model provides comprehensible scaffolding; legacy enterprise environments; reference model in Git training and certification materials.

Common criticisms

Driessen himself in 2020 noted GitFlow was not designed for continuously-deployed web applications — using it for that context produces unnecessary friction
long-lived develop branch accumulates merge conflicts and hides work from CI
release branches add ceremony without delivering value in continuous-deployment contexts
the structured model can become rigid commitment to ceremony rather than adaptive workflow
competing alternatives (GitHub Flow, GitLab Flow, Trunk-Based Development) are simpler and better-suited to most modern web development
many teams adopt GitFlow as default without considering whether their context fits Driessen's intended use
complexity barrier for new contributors.

Lineage

Siblings: Trunk-Based Development