Quick Start with Gitflow: A Practical Branching Guide

Gitflow is a branching model for Git, introduced by Vincent Driessen in 2010. Rather than leaving every developer to invent their own way of organizing branches, it defines a strict, predictable structure: a set of long-lived branches that always exist, and a set of short-lived supporting branches for the actual work of building features, cutting releases, and shipping urgent fixes.

The appeal is consistency. On a team using Gitflow, anyone can look at the repository and immediately understand what a branch is for, where new work should start, and how a change makes its way into production. That shared vocabulary is the whole point — it turns branching from a matter of personal habit into a documented process.

This guide is a practical quick start. We’ll cover the branches, the commands, and a realistic end-to-end workflow, so you can start using Gitflow on a real project today.

Gitflow revolves around two branches that live forever:

• main (historically called master) — always reflects production-ready code. Every commit on main is a released, tagged version. You never commit to it directly.
• develop — the integration branch. It holds the latest delivered development changes for the next release. This is where feature work comes together and where the next release is assembled.

Think of develop as the staging ground for tomorrow’s release, and main as the record of everything that has actually shipped. The gap between them is your work-in-progress.

Around those two, Gitflow defines three types of short-lived branches. Each has a clear purpose, a defined branch-off point, and a defined merge target.

• feature/* — branch off develop, merge back into develop. Used for building a single new feature. Named like feature/user-authentication.
• release/* — branch off develop, merge into both main and develop. Created when develop has enough features for a release. This is where you stabilize: bump version numbers, fix last-minute bugs, finalize release notes.
• hotfix/* — branch off main, merge into both main and develop. Used to patch a production bug urgently, without waiting for the next release cycle.

The rule of thumb: features and releases grow out of develop, while hotfixes grow out of main because they respond to something already in production.

You can follow the Gitflow model with plain Git commands, but the git-flow helper tool wraps the whole process into a handful of high-level commands. On most systems it installs easily:

# macOS
brew install git-flow-avh

# Debian / Ubuntu
apt-get install git-flow

Once installed, initialize it inside your repository:

git flow init

It prompts you for branch naming conventions — in almost all cases the defaults (main/master, develop, and the feature/, release/, hotfix/ prefixes) are exactly what you want, so you can press Enter through them. Your repository now has both main and develop, and you’re ready to work.

Here is the day-to-day loop, shown with the git flow helper alongside the equivalent plain-Git commands so you understand what’s happening underneath.

1. Start a feature.

git flow feature start user-authentication
# equivalent to:
# git checkout -b feature/user-authentication develop

Do your work, committing to the feature branch as normal.

2. Finish the feature. This merges it back into develop and deletes the feature branch.

git flow feature finish user-authentication

3. Cut a release when develop is ready. Stabilize on this branch — version bumps and final bug fixes only, no new features.

git flow release start 1.2.0

4. Finish the release. This merges into main, tags it with the version, merges back into develop, and removes the release branch.

git flow release finish 1.2.0

5. Ship a hotfix when production breaks and can’t wait:

git flow hotfix start 1.2.1
# fix the bug, commit
git flow hotfix finish 1.2.1

The hotfix lands in main (tagged) and also flows back into develop, so the fix isn’t lost in the next release.

Gitflow is a strong fit when you ship versioned releases — desktop software, mobile apps, libraries, or any product where multiple versions exist in the wild and you occasionally need to patch an older one. Its explicit release and hotfix branches map cleanly onto that reality.

It is often too heavy for teams practicing continuous deployment, where every merge to the main branch goes straight to production many times a day. In that world the long-lived develop branch and formal release branches add ceremony without much payoff, and lighter models like trunk-based development or GitHub Flow tend to serve better.

A good question to ask: do we release in discrete, named versions, or do we continuously deploy whatever is on the main branch? The first answer points to Gitflow; the second usually points away from it.

Gitflow gives a team a shared, documented answer to the question “where does this change go?” Two permanent branches — main for what’s shipped and develop for what’s next — anchor the model, while feature, release, and hotfix branches handle the day-to-day flow of work with clear rules about where they start and end.

Start simple: git flow init, then feature start and feature finish for your first change. Add releases and hotfixes to your vocabulary as you need them. And keep the trade-off in mind — Gitflow rewards teams that ship versioned releases, and gets in the way of teams that deploy continuously. Pick the model that matches how you actually ship.