Branching Workflows

Knowing how to create and merge branches is one thing. Knowing how to organise them into a coherent workflow is another. A branching workflow is a set of conventions your team adopts — a shared understanding of what branches exist, what they represent, and how work moves between them. Choosing the right workflow depends on your project's size, team structure, and release process.

Two Fundamental Branch Types

Before looking at specific workflows, it helps to understand the two fundamental types of branches that every workflow is built from:

Long-Running Branches

Long-running branches exist for the lifetime of the project. They are permanent and represent stable states of the codebase at different levels of readiness. Work is never done directly on them — instead, work flows into them from shorter-lived branches once it is ready.

Topic Branches (Feature Branches)

Topic branches are short-lived. Each one is created for a specific piece of work — a feature, a bug fix, an experiment — and deleted once that work is merged. They exist for minutes, days, or weeks, not months. Because creating and merging branches is cheap in Git, creating topic branches liberally is actively encouraged.

Workflow 1 — The Simple Two-Branch Model

The simplest stable workflow uses two long-running branches:

main      ─────────────────────────────── (always stable, deployed)
              ↑         ↑         ↑
develop   ───────────────────────────────  (integration branch)
              ↑         ↑
feature   ──────     ──────               (short-lived topic branches)

Feature branches are created off develop, worked on independently, and merged back into develop when complete. When develop reaches a stable state ready for release, it is merged into main and tagged with a version number.

This model gives you a clear separation between work in progress and production-ready code.

Workflow 2 — Progressive Stability (Multi-Lane)

Larger projects extend the two-branch model with additional stability lanes. Each branch represents a different level of confidence:

main        ───  (released, fully stable)
next        ───  (testing complete, release candidate)
develop     ───  (integration, passing tests)
feature/*   ───  (in-progress work)

Commits graduate upward — from feature branches into develop, from develop into next once tested, from next into main once a release is confirmed. At any given moment, the farther down the list a branch is, the more stable and well-tested its contents are.

The mental model for this is silos — each branch represents a silo of a given stability level, and work moves up through the silos as it matures.

This model is used by large open source projects like the Linux kernel and Git itself. For most smaller teams and products, the two-branch model is sufficient.

Workflow 3 — Topic Branches Only (Trunk-Based Development)

At the other end of the spectrum is trunk-based development — a workflow where there is only one long-running branch (main) and all work happens on very short-lived topic branches:

main     ────────────────────────────────  (always deployable)
              ↑    ↑    ↑    ↑    ↑
feature  ───  ──   ──   ──   ──   ──       (merged quickly, deleted)

Feature branches are created, completed, and merged back into main quickly — ideally within hours or a day or two. The emphasis is on keeping branches short-lived to minimise divergence and integration pain.

This workflow requires confidence in your automated testing, since main must always be deployable. It is common in teams practising continuous integration and continuous deployment (CI/CD).

Workflow 4 — Git Flow

Git Flow is a structured branching model originally proposed by Vincent Driessen in 2010. It defines five branch types:

main       ──────────────────────────────────────
                ↑                    ↑
hotfix          └── fix ─────────────┘
develop    ─────────────────────────────────────
                ↑         ↑
release         └── prep ─┘
                ↑
feature         └── work ─┘

Git Flow is well-suited to projects with scheduled, versioned releases — software with a defined release cycle rather than continuous deployment. For projects that deploy continuously, it can feel heavy.

Workflow 5 — GitHub Flow

GitHub Flow is a simplified, pull-request-based workflow designed for teams deploying continuously:

1. Create a descriptively named branch off main.
2. Make commits — push regularly to the remote branch.
3. Open a pull request to start discussion and review.
4. Incorporate feedback with additional commits.
5. Merge into main once approved.
6. Deploy immediately after merging.
7. Delete the branch.

main     ─────────────────────────────────────
               ↑
feature/login ──── commit ── commit ─ (PR) ──┘

There is no develop branch and no release branch — main is always deployable. The pull request is central to the workflow: it is where code review, discussion, and CI checks happen before anything reaches main.

GitHub Flow is the default model for most open source projects and teams working on web services.

Choosing a Workflow

No workflow is universally correct. The right choice depends on how often you release, how large your team is, and how much process overhead your project can absorb. The most important thing is that your team agrees on the conventions and follows them consistently — an inconsistently applied workflow is worse than a simple one applied well.

Naming Conventions

Whatever workflow you adopt, consistent branch naming makes the branch list readable and makes the purpose of each branch immediately clear:

Separating the type from the description with a / creates a namespace — tools like GitHub and GitLab visually group branches that share the same prefix, making long branch lists easier to navigate.

The Key Principle

All branching workflows share one underlying principle: keep stable code stable. The structure of your branches reflects the structure of your confidence in the code. Long-running stable branches only receive work that has been verified elsewhere first. Short-lived topic branches are where uncertainty lives — experiments happen there, and only the results that prove out get promoted.

The specific workflow matters less than the discipline of applying it consistently.