Workflows

Release Branch Workflow

Explain when to cut a release branch, when to freeze features, and how to flow fixes back to main.

Who This Is For

Teams turning commands into repeatable routines
Readers who need sequencing, branch, and sync discipline

Prerequisites

Basic understanding of fetch, pull, push, and branches
A sense of how and why branches diverge

Common Risks

Copying a workflow without checking branch state
Choosing the wrong integration path on shared branches

Where this workflow fits

Release Branch WorkflowCut release branch from develop for feature freeze and bug fix. After fixes, merge to main for release and backmerge to develop.

Start release cycle

main

2.02.1

develop

D1D2D3

release / hotfix

release/2.2.0

R1R2

hotfix/login-timeout

Release branches are useful when the team needs a stable lane for test, packaging, and release-only fixes while main keeps moving.

Suggested sequence

1. cut a release branch from a stable mainline

git switch main
git pull --ff-only
git switch -c release/2.4.0

2. freeze features and accept only release-related fixes

That usually means bug fixes, config adjustments, docs, and packaging changes only.

3. merge the final release fixes back into main

git switch main
git merge release/2.4.0

Why this order is safer

Release work becomes easier when "prepare this version" is separated from "continue building new work."

Common mistakes

continuing to add features after cutting the release branch
fixing release-only issues without flowing them back to main
leaving release branches alive far beyond the release window

Previous / Next

PreviousOpen Source Contribution with Fork + PRWorkflows NextBackporting with Cherry-pickWorkflows