What it is: A release branch is a Git branch created specifically to prepare, stabilize, and ship a particular version of a project — separate from the branch where ongoing, everyday development continues. Once created, a release branch typically only receives careful, targeted fixes needed to get that specific version ready, rather than new features or unrelated changes.

Why it exists: Software teams constantly need to do two different things at the same time: keep building new features for the future, and carefully finish, test, and ship a specific version right now. If both activities happened on the exact same branch, every new, half-finished feature commit would risk destabilizing the version the team is trying to release. A release branch exists to let these two activities happen safely, side by side, without interfering with each other.

Where it’s used: Release branches are common in projects that ship distinct, numbered versions — desktop applications, mobile apps, libraries, and any software with a formal release cycle. They are less commonly needed in projects that deploy continuously many times a day directly from a single main branch, though even those teams sometimes use a release branch for major, carefully staged versions.

Practical example: A team building a mobile app is preparing to ship version 3.0. Two weeks before the planned release date, they create a branch called release/3.0. From that point on, engineers continue adding new features for version 3.1 on the main development branch, while a smaller group focuses exclusively on testing and fixing bugs found specifically in release/3.0, until it’s ready to actually ship.

In the earliest days of a small project, a single main branch is often enough: one or two people commit directly to it, and shipping simply means using whatever is currently there. As a team and a codebase grow, though, a specific tension appears: development on new features never really stops, but shipping a specific version requires a period of focus — testing thoroughly, fixing the last remaining bugs, and refusing to add anything new that could introduce fresh, untested risk right before release.

Without a dedicated release branch, this creates a difficult choice: either freeze the entire team’s work on the main branch while one version stabilizes — which wastes everyone else’s time — or keep merging new feature work into the same branch being prepared for release, which risks reintroducing bugs or instability right when the team can least afford it. A release branch resolves this tension directly, by giving the stabilization work its own dedicated, protected space.

The core problem release branches solve: how do you let ongoing feature development continue at full speed, while simultaneously giving a specific, about-to-ship version the calm, focused, bug-fix-only environment it needs to stabilize safely?

A branch in Git is simply a named, movable pointer to a specific commit — and, by extension, to the entire history of commits leading up to it. When you create a new branch, you’re not copying the whole project; you’re just creating a new pointer that starts out at the same commit as wherever you branched from, and can then move independently as new commits are added to it.

This is what makes branching so lightweight and cheap in Git: creating a release branch doesn’t duplicate the project’s files anywhere — it simply marks a starting point from which a separate line of commits can grow, completely independent of what happens on the branch it came from.

Because branches are this lightweight, teams can freely create as many as they need — including a fresh release branch for every version — without worrying about storage cost or complexity at the Git level. The complexity of managing releases comes entirely from the human workflow layered on top, which the rest of this guide explores.

flowchart LR
    A["Main development branch"] --> B["Create release/X.Y branch at feature-freeze point"]
    B --> C["Team keeps adding new features to main"]
    B --> D["Only bug fixes applied to release/X.Y"]
    D --> E["Testing and stabilization on release/X.Y"]
    E --> F{"Ready to ship?"}
    F -->|No, bug found| D
    F -->|Yes| G["Tag the release and publish it"]
    G --> H["Merge release/X.Y fixes back into main"]
    

Step by step, in plain language: first, at a point the team calls “feature freeze,” they create a new branch — typically named something like release/3.0 — starting from the current state of the main development branch. Second, from that moment on, ongoing feature development continues on the main branch as normal, unaffected by whatever happens on the release branch. Third, the release branch itself only receives carefully chosen bug fixes discovered during focused testing — no new features, and no unrelated changes. Fourth, the team repeats a cycle of testing, finding issues, and fixing them directly on the release branch until it’s judged stable and ready. Fifth, once ready, the team creates a formal, permanent marker called a “tag” at that exact commit — a fixed label such as v3.0.0 that will always point to precisely this version — and publishes the release. Finally, because bug fixes made on the release branch were never on the main branch, the team merges those fixes back into main, ensuring the ongoing development line also benefits from them and doesn’t accidentally reintroduce the same bugs later.

Notice that this entire cycle can repeat continuously — while one release branch is in its stabilization phase, main is often already accumulating features for the version after that, and in larger projects, more than one release branch (for different supported versions) can exist and be maintained at the same time.

A feature branch is created by a single developer or small group to build one specific piece of new functionality, usually merged back into the main branch once finished, and then deleted — it’s short-lived and forward-looking. A release branch, by contrast, exists to stabilize an already largely finished set of work for shipping, accepts only fixes rather than new features, and may live on longer to support that version afterward. A tag is different from both: it’s not a branch at all, but a fixed, permanent label pointing at one specific, unchanging commit — it never moves and never receives new commits directly.

Whichever convention a team picks, the value comes from consistency: anyone on the team should be able to look at the list of branches and immediately identify which ones are release branches, and which specific version each one corresponds to, without needing to ask.

Many projects, especially ones with a wide user base that can’t all upgrade instantly, continue supporting older released versions for a period of time after a newer version ships. This means a release branch like release/2.0 might stay alive and receive occasional bug fixes — particularly urgent security fixes — long after release/3.0 has already shipped and even after release/4.0 is underway.

When a fix needs to apply to more than one supported version at once, teams use a process called backporting: taking a fix that was written for the current release branch (or for main) and carefully reapplying it to an older, still-supported release branch as well. This is essentially a targeted, deliberate act of copying a specific change across branches, rather than merging entire lines of history together, since the older branch has likely diverged significantly from the newer one by that point.

The core trade-off to internalize: release branches trade a small amount of process overhead — creating branches, merging fixes back, occasionally backporting — for a large reduction in the risk of shipping something unstable, or blocking ongoing development while a release stabilizes. For projects with a real release cadence and real users depending on stability, this trade almost always favors using release branches.

Backporting, covered in Chapter 8, has its own security dimension: when a vulnerability is discovered and fixed, teams supporting multiple older release branches need a clear, fast process for backporting that fix to every still-supported version — a slow or inconsistent backporting process can leave older, still-widely-used versions exposed even after a fix is known and already shipped elsewhere.

It’s also worth remembering that once a release branch ships and is tagged, that historical record is meant to stay trustworthy — rewriting the history of an already-released branch (for example, to hide a mistake) undermines the ability to reliably trace exactly what code was actually shipped in a given version, which matters enormously during a security investigation or an audit.

The Short-Lived Release Branch Pattern creates the branch shortly before a release, ships quickly, merges fixes back, and lets the branch fade into history once no longer needed — common for projects without a long-term-support commitment.

The Long-Term-Support Pattern deliberately keeps certain release branches alive far longer, with a formal policy about how long each one will keep receiving backported fixes, giving users a predictable stability guarantee.

The Trunk-Based Alternative is worth knowing about even though it skips release branches almost entirely: some teams ship directly and continuously from main, using feature flags to hide unfinished work instead of isolating it on a branch — a different, equally valid strategy for a different set of needs (typically fast-moving, continuously deployed web services rather than versioned, installed software).

Common anti-patterns to avoid: the Feature Creep Release Branch (gradually allowing new features in “just this once” until the branch is no more stable than main); the Forgotten Merge-Back (fixing bugs on the release branch but never merging them into main, so the same bugs resurface in the next version); and the Zombie Release Branch (a branch nobody remembers the purpose of, left indefinitely without a clear support policy, confusing anyone who stumbles across it later).

Common mistakes beginners make: assuming a release branch is a special Git feature rather than just a regular branch used with discipline; forgetting to merge release-branch fixes back into main, letting the same bug quietly reappear later; and creating a release branch far too early, before the team has actually agreed on what will and won’t be included.