What Is Git Flow?
A deep, no-assumptions walkthrough of the classic branching model — its five branch types, how a release actually moves through them, and when it's genuinely the right choice for a team.
Imagine a large theater production, staged night after night for months. There’s the polished show currently running for paying audiences, a separate rehearsal space where the next act is being pieced together, individual actors practicing their own solo scenes in private studios before bringing them to rehearsal, a dress-rehearsal stage where the whole next act gets a final, careful once-over before opening night, and a small backstage team ready to rush out an emergency fix if something breaks during tonight’s live show. Git Flow organizes a software project’s branches in almost exactly this way — a strict structure with a distinct, named space for every kind of work, so nothing risky ever accidentally ends up in front of the live audience.
1What Is Git Flow?
Let’s build a precise, plain-English definition before exploring its structure in depth.
The Simple Definition
Git Flow is a branching model — a formal, agreed-upon set of rules for how a team organizes and names its branches — designed around scheduled software releases. Rather than everyone working loosely off a single main branch, Git Flow defines several distinct, long-lived and short-lived branch types, each with a clear, specific purpose, and clear rules for how work moves between them.
Think of a hospital with clearly labeled wards — emergency, general recovery, surgery prep, and outpatient consultation — instead of one single, undifferentiated waiting room. Git Flow gives a codebase that same kind of clear separation, so everyone instantly knows where a particular piece of work belongs and what stage it’s currently at.
Why Git Flow Was Created
Git Flow was first described publicly in 2010 by developer Vincent Driessen, at a time when many teams were shipping software through scheduled, versioned releases rather than continuous, many-times-a-day deployments. Teams needed a reliable way to keep ongoing feature development separate from the stable, already-shipped version of their product, while still being able to urgently patch that shipped version if something broke — all without those different streams of work interfering with each other.
Git Flow isn’t a Git feature or command — it’s purely a convention, a shared agreement among a team about how to name and use ordinary Git branches. Nothing about it requires special tooling, though some tools do exist to help automate its rules.
2The Five Branch Types of Git Flow
Everything about Git Flow revolves around these five categories of branches, each with its own job.
main
Always reflects the official, currently released version of the software — production-ready at every single point in time, never containing unfinished work.
develop
The integration branch where all finished features accumulate ahead of the next release — stable enough to build on, but not yet ready to be shipped.
feature/*
Created off develop for building one specific piece of new functionality, merged back into develop once that feature is complete.
release/*
Branched off develop when it’s time to prepare an upcoming release — used for final testing, bug fixing, and polishing, but not new features.
hotfix/*
Branched directly off main to urgently patch a critical problem found in the currently live, released version of the software.
graph TD
Main[main - always production-ready]
Develop[develop - integration branch]
Feature[feature branches]
Release[release branches]
Hotfix[hotfix branches]
Develop --> Feature
Feature --> Develop
Develop --> Release
Release --> Main
Release --> Develop
Main --> Hotfix
Hotfix --> Main
Hotfix --> Develop
3main and develop — The Two Backbones
Everything else in Git Flow ultimately connects back to these two permanent, ever-present branches.
The main branch’s entire purpose is stability: at literally any moment, whatever is on main should be exactly what’s currently deployed and running for real users. Nothing experimental or half-finished ever lives here directly — it only receives fully completed, tested releases and urgent hotfixes. The develop branch, by contrast, is where the team’s forward momentum actually happens: it’s constantly gaining new, finished features, always representing “everything we’ve completed so far, aimed at the next release,” even while that next release isn’t ready to ship yet.
Develop is not the same thing as “unstable” or “broken.” It should still generally work — it simply hasn’t been through the final release preparation and testing that main requires before something is considered truly shippable.
4Feature Branches — Building New Work
Feature branches are where the vast majority of a team’s actual day-to-day coding happens.
Branch off from develop
A developer creates a new feature branch starting from the current tip of develop, giving it a clear, descriptive name for the work it will contain.
Build the feature in isolation
All the commits for this one piece of functionality happen here, undisturbed by other in-progress work elsewhere on the project.
Merge back into develop
Once the feature is complete and reviewed, it’s merged back into develop, joining the growing collection of work aimed at the next release.
Delete the feature branch
With its work now safely part of develop, the feature branch has served its purpose and is typically deleted to keep the repository tidy.
A Git Flow feature branch is conceptually identical to the general “feature branch” workflow used by many teams outside Git Flow entirely — the difference is simply that Git Flow specifically requires it to branch from, and merge back into, develop rather than main.
5Release Branches — Preparing to Ship
This branch type is one of Git Flow’s most distinctive contributions, and it deserves careful attention.
When develop has accumulated enough finished features to justify a new release, the team creates a release branch from develop’s current state. From this point forward, the release branch is meant for polishing only — fixing small bugs found during final testing, updating version numbers, refining documentation — and explicitly not for starting any brand-new features. This deliberate freeze gives the team a stable, shrinking target to finish testing against, rather than trying to test against a develop branch that keeps changing underneath them.
A release branch is like the final dress rehearsal before a play opens — no new scenes are being written at this point, only small adjustments to lighting, timing, and delivery based on what the rehearsal reveals.
Once the release branch is genuinely ready, it’s merged in two directions at once: into main, to officially become the newly released version, and into develop, so that any small fixes made during this final polishing phase aren’t lost from ongoing future development.
sequenceDiagram
participant D as develop
participant R as release/1.2.0
participant M as main
D->>R: Branch off when ready to prepare a release
R->>R: Fix small bugs, polish, update version
R->>M: Merge into main once ready
R->>D: Also merge back into develop
M->>M: Tag this commit as the official release
6Hotfix Branches — Emergency Repairs
Hotfix branches exist for exactly one situation: something is broken in production, right now, and it can’t wait for the next scheduled release.
A hotfix branch is created directly off main — not develop — because the whole point is to fix whatever is currently live, without waiting for or being tangled up in unfinished, in-progress feature work. Once the fix is made and verified, the hotfix branch merges back into main, immediately becoming the new official released version, and is also merged into develop, so the underlying problem doesn’t quietly resurface in the next regular release.
A hotfix branch should stay as narrow and minimal as possible — it exists to fix the specific emergency, not to sneak in other small improvements while you’re already in there.
A Critical Bug Discovered After Release
If a serious bug is found in the live, shipped version of the software, a hotfix branch lets the team fix and ship a correction almost immediately, without disturbing whatever unfinished features are currently sitting on develop.
7The Complete Lifecycle of a Release
Let’s trace the entire journey a typical version of the software takes through Git Flow’s structure, start to finish.
Features accumulate on develop
Multiple feature branches are built, reviewed, and merged into develop over time, gradually building up everything intended for the next version.
A release branch is cut
Once enough is ready, a release branch is created from develop’s current state, and new-feature work continues separately on develop for the version after this one.
The release is polished and tested
Only bug fixes, documentation updates, and version bumps happen on the release branch during this stabilization period.
The release ships
The release branch merges into main, which is then tagged with the new version number, officially marking this exact point as the released version.
Fixes flow back into develop
The same release branch also merges into develop, ensuring any small fixes made during stabilization aren’t lost from future work.
Emergencies get a hotfix, if needed
If a serious problem is later discovered in this now-live release, a hotfix branch off main handles it, merging back into both main and develop once resolved.
8Git Flow vs. GitHub Flow vs. Trunk-Based Development
Git Flow is far from the only branching model in common use — here’s how it compares to two other popular approaches.
| Model | Complexity | Best Fit For |
|---|---|---|
| Git Flow | High — five distinct branch types with strict rules | Scheduled, versioned releases; software supporting multiple live versions at once |
| GitHub Flow | Low — just main plus short-lived feature branches | Continuous deployment, web apps shipped many times a day |
| Trunk-Based Development | Very low — very short-lived branches merged constantly | Teams prioritizing extremely frequent integration and minimal drift |
Git Flow’s extra structure exists specifically to support the idea of multiple, distinct, simultaneously supported versions of software — something continuously deployed web applications, which only ever have “the current live version,” generally don’t need.
9When Git Flow Is a Good Fit
Understanding the kinds of projects Git Flow was actually designed for helps clarify when to reach for it.
Desktop and Mobile Applications
Software distributed as discrete, numbered versions — where users explicitly install or update to a specific release — maps naturally onto Git Flow’s structure of clearly separated, versioned releases.
Software with Long-Term Support Versions
Projects that must keep patching several older, still-supported releases simultaneously benefit enormously from Git Flow’s clean separation between main, develop, and dedicated hotfix branches.
Teams with Scheduled Release Cycles
Organizations that ship on a predictable cadence — monthly, quarterly, or otherwise — find the release-branch stabilization period a natural fit for their existing testing and QA processes.
10Advantages and Trade-offs
Git Flow brings real structural clarity, but that structure has genuine costs too.
Advantages
- Gives every piece of work an unambiguous, clearly named home, reducing confusion on larger teams.
- Keeps main permanently stable and safe to deploy or distribute at any time.
- Provides a clean, well-defined process for urgent hotfixes that doesn’t disturb ongoing feature work.
- Naturally supports maintaining multiple, simultaneously live release versions.
- The release-branch stabilization period fits well with formal QA and testing cycles.
Disadvantages / Trade-offs
- Considerably more complex than lighter models, with more branch types and merge directions to remember.
- Can feel like unnecessary overhead for teams practicing continuous deployment with no discrete “versions.”
- The dual-merge requirement for releases and hotfixes (into both main and develop) is an extra step that’s easy to forget.
- Long-lived develop and release branches can still accumulate drift and conflicts if not managed carefully.
11Security Considerations
Git Flow’s structure naturally supports a few security-relevant practices worth calling out explicitly.
Branch Protection on main and develop
Because these two branches are so central, many teams configure their hosting platform to block direct pushes to them entirely, requiring every change to arrive through a reviewed pull request instead.
Controlled Hotfix Access
Since hotfixes go straight to the live, production-facing main branch, some teams restrict who is allowed to create or approve hotfix branches, treating it as a higher-trust, more carefully reviewed operation.
Auditable Release History
Tagging each release on main creates a clear, permanent, auditable record of exactly what code was shipped and when, which matters for compliance and incident investigation in regulated industries.
12Best Practices and Common Mistakes
A practical checklist for teams actually running Git Flow day to day.
Keep release branches focused on stabilization
Resist the temptation to sneak new features into a release branch — its job is polishing what’s already there, not adding more.
Always merge releases and hotfixes both ways
Forgetting to merge a release or hotfix branch back into develop is one of the most common Git Flow mistakes, silently losing fixes from future work.
Letting feature branches live for months
A feature branch that drifts too far from develop before merging back defeats much of the purpose of keeping develop a reliable, up-to-date integration point.
Committing directly to main
Bypassing the structure entirely and pushing straight to main undermines the whole point of Git Flow’s carefully separated branch types.
Problem
A team adopts full Git Flow for a fast-moving web application that gets deployed to production many times a day, with no concept of distinct, numbered “releases.”
Why It’s Harmful
The extra branch types, dual-merge rules, and release-stabilization ceremony add real process overhead without providing any corresponding benefit, since there’s no scenario where multiple past versions need separate, simultaneous support.
Correct Approach
Choose a lighter model like GitHub Flow or trunk-based development for continuously deployed software, and reserve Git Flow’s full structure for projects that genuinely ship distinct, numbered versions.
13Real-World and Industry Examples
Git Flow has left a lasting mark on how many teams, tools, and industries think about branching.
Desktop Software with Versioned Installers
Applications distributed as numbered installers or updates — rather than continuously deployed web services — often adopt Git Flow’s structure to naturally match how their releases are actually shipped to users.
Enterprise and Regulated Industries
Organizations in finance, healthcare, and other regulated sectors frequently favor Git Flow’s clear, auditable release process, which pairs naturally with formal change-approval requirements.
Dedicated Tooling Support
Git Flow’s popularity led to purpose-built command-line extensions that automate its branch creation and merging rules, reducing the chance of manual mistakes for teams that adopt it.
14Frequently Asked Questions
No — it’s purely a naming and workflow convention that teams agree to follow using ordinary Git branches. Some optional third-party tools exist to help automate its specific rules.
No — genuinely urgent, critical fixes to the live version go through a dedicated hotfix branch instead, which is designed to be faster and more direct than the full release process.
Merging into main makes it the official new release; merging into develop ensures any small bug fixes made during the release’s final polishing phase aren’t lost from ongoing future development.
It remains popular for versioned, non-continuously-deployed software, though many web-focused teams practicing frequent deployment have shifted toward lighter models like GitHub Flow instead.
In the standard model, feature branches are always created from develop, keeping new work clearly separated from both the stable main branch and any in-progress release stabilization.
Like a feature branch, it’s typically deleted once its work has been safely merged into both main and develop, since it has no further purpose after that point.
15Summary and Key Takeaways
Git Flow is a structured branching model built around two permanent branches — main and develop — supported by three short-lived branch types: feature, release, and hotfix, each with a clear, specific job. It’s especially well suited to software shipped as distinct, numbered versions, where maintaining a permanently stable main branch and a clean process for both scheduled releases and emergency fixes genuinely matters. For continuously deployed software with no real concept of “versions,” lighter models like GitHub Flow often serve just as well with far less process overhead — making the right choice ultimately depend on how a team actually ships its software.
Key Takeaways
- Five branch types, five jobs — main, develop, feature, release, and hotfix each serve one clear purpose.
- main is always shippable — it only ever receives fully finished releases and urgent hotfixes.
- develop is the integration point — finished features accumulate here ahead of the next release.
- Release branches freeze for stabilization — only fixes and polish happen there, never new features.
- Hotfixes branch from main, not develop — keeping emergency fixes separate from unfinished, in-progress work.
- A convention, not a Git feature — Git Flow is purely a shared team agreement, built entirely on ordinary branches.
- Fit matters most — Git Flow shines for versioned software, while continuously deployed products often prefer a lighter model.