Release Branches

The Hook (The "Byte-Sized" Intro)

You're about to release v2.0. The feature work is done, but the team keeps pushing new features to main. You need a quiet room where only bug fixes land — no new features, no experiments. That's a release branch: a short-lived branch cut from main where the code is polished, stabilized, and eventually tagged for release.

📖 What is a Release Branch?

A release branch is a temporary branch used to stabilize a specific version before release. Only bug fixes and release preparation (version bumps, documentation) are allowed — no new features.

Conceptual Clarity

Release branch lifecycle:

Phase	What Happens
Cut	Branch from main when features are complete
Stabilize	Only bug fixes and final polishing
Tag	Create the release tag on this branch
Merge back	Merge fixes back to main
Delete	Remove the branch after release

When to use release branches:

Scenario	Use Release Branch?
Simple project, CD to production	❌ Tag directly on main
Multiple features, needs stabilization	✅
Supporting multiple versions (v1.x, v2.x)	✅
Enterprise release with QA cycle	✅

Real-Life Analogy

A release branch is like a final manuscript review before publishing. The book's content is done, the editing room only allows corrections — no new chapters. Once approved, it's printed (tagged) and the edits go back to the main draft.

Visual Architecture

gitGraph commit id: "A" commit id: "B" branch release/2.0 commit id: "Fix bug" commit id: "Bump version" commit id: "v2.0.0" tag: "v2.0.0" checkout main merge release/2.0 commit id: "C (new feature)"

Why It Matters

Isolation: New feature work on main doesn't destabilize the release.
QA focus: Testers have a stable target to validate.
Parallel work: Developers continue working on main while the release stabilizes.
Multiple versions: Enables maintaining v1.x patches while developing v2.x.

Code

bash

# ─── Cut a release branch ───
git switch main
git pull origin main
git switch -c release/2.0

# ─── Only bug fixes allowed ───
git commit -m "fix: resolve payment timeout"
git commit -m "chore: bump version to 2.0.0"

# ─── Tag the release ───
git tag -a v2.0.0 -m "Release v2.0.0"
git push origin v2.0.0

# ─── Merge fixes back to main ───
git switch main
git merge release/2.0

# ─── Clean up ───
git branch -d release/2.0
git push origin --delete release/2.0

Key Takeaways

Cut a release branch when feature work is done and stabilization begins.
Only allow bug fixes and release prep — no new features.
Tag the release on the release branch, then merge back to main.
Delete the release branch after merging.

Interview Prep

Q: When should you use a release branch instead of tagging main directly? A: When the codebase needs a stabilization period (QA testing, bug fixing) before release, or when development continues on main in parallel. For simple projects with continuous deployment, tagging main directly is fine.
Q: What types of commits are allowed on a release branch? A: Only bug fixes, version bumps, documentation updates, and other release preparation. New features are never added to a release branch — they go to main for the next release.
Q: What happens to the release branch after the release? A: The bug fixes are merged back to main (so they're included in future releases), and the release branch is deleted. Some teams keep long-lived release branches for maintaining older versions (e.g., release/1.x for v1 patches).