Release Branch Management Template

What This Template Is For

Every team that ships software needs a branching strategy, but most teams never write it down. Engineers learn the unwritten rules by asking in Slack, making mistakes, or reading old pull requests. New hires break the process because nobody told them how it works. Hotfixes get merged to the wrong branch. Release candidates get contaminated with unfinished work.

This template documents your release branching strategy in one place: branch naming conventions, merge policies, the release candidate process, hotfix procedures, and environment mapping. It is designed for teams that deploy on a cadence (weekly or per-sprint releases) rather than continuous deployment. If your team deploys multiple times per day from main, you need the deployment checklist template and feature toggles instead of release branches.

The Technical PM Handbook covers how product managers should think about release engineering without getting lost in git internals. The release planning template handles the higher-level planning of what goes into each release.

When to Use This Template

• New team setup: Document the branching strategy before the first sprint, not after the first merge conflict.
• Onboarding new engineers: Hand them this document on day one so they do not need to reverse-engineer the workflow.
• After a release incident caused by branch confusion: If a hotfix went to the wrong branch or unfinished code shipped, tighten the process.
• When migrating to a new workflow: Transitioning from Gitflow to trunk-based development (or vice versa) requires a clear written plan.

Step-by-Step Instructions

Step 1: Choose a Branching Model (10 minutes)

Pick the model that matches your team's release cadence and complexity.

• ☐ Trunk-based development: All work merges to main. Releases are tagged commits. Best for teams deploying daily or more. Requires feature toggles for incomplete work.
• ☐ Release branches: Features merge to main. A release branch is cut when ready. Best for teams deploying weekly or per-sprint. Allows release-specific stabilization.
• ☐ Gitflow: Develop, release, and hotfix branches with strict merge directions. Best for teams managing multiple release versions simultaneously (mobile apps, on-premise software).
• ☐ Document the chosen model and the rationale

Step 2: Define Branch Naming and Policies (5 minutes)

Standardize how branches are named and who can merge to protected branches.

• ☐ Define naming conventions for each branch type
• ☐ Set merge policies (squash merge, merge commit, rebase)
• ☐ Configure branch protection rules in your git host (GitHub, GitLab)
• ☐ Document required approvals for each merge target

Step 3: Document the Release Process (10 minutes)

Write out the step-by-step release process from branch creation to production deployment.

• ☐ When and how to create a release branch
• ☐ What changes are allowed on the release branch (bug fixes only, no new features)
• ☐ QA and staging deployment process
• ☐ Release approval and production deployment
• ☐ Post-release merge-back to main

Step 4: Define the Hotfix Process (5 minutes)

Hotfixes need a fast path that bypasses the normal release cycle.

• ☐ When to use a hotfix (P0/P1 production issues only)
• ☐ Where to branch from (release branch or main, depending on model)
• ☐ Approval process (expedited review, minimum one approver)
• ☐ Merge-back requirements (hotfix must reach both release and main)

The Release Branch Management Template

Team: [Team name]

Branching Model: [Trunk-based / Release branches / Gitflow]

Release Cadence: [Daily / Weekly / Per-sprint / Monthly]

Git Host: [GitHub / GitLab / Bitbucket]

Last Updated: [Date]

Branch Types and Naming

Merge Policies

Environment Mapping

Release Process

Step 1: Create Release Branch

When: [Day of week / Sprint day] or when main is feature-complete for the release.

git checkout main
git pull origin main
git checkout -b release/v[X.Y.Z]
git push origin release/v[X.Y.Z]

• ☐ Branch created from a green commit on main (CI passing)
• ☐ Release branch deployed to staging
• ☐ Team notified: "Release branch release/v[X.Y.Z] is cut. Main is now open for next release features."

Step 2: Stabilization (Release Branch)

Duration: [X] days

Allowed changes: Bug fixes and release-specific configuration only. No new features.

• ☐ QA runs full regression on staging
• ☐ Bug fixes merged to release branch via bugfix branches
• ☐ Release notes drafted
• ☐ No feature branches merged after branch cut

Step 3: Release Approval

• ☐ QA sign-off: all critical and high-priority bugs fixed
• ☐ PM sign-off: scope is correct, release notes reviewed
• ☐ Tech lead sign-off: no known P0/P1 issues
• ☐ Tag the release: git tag v[X.Y.Z] && git push origin v[X.Y.Z]

Step 4: Production Deploy

• ☐ Deploy release tag to production (follow deployment checklist)
• ☐ Post-deploy verification complete
• ☐ Stakeholders notified: "v[X.Y.Z] is live"

Step 5: Merge Back

• ☐ Merge release branch to main: git checkout main && git merge release/v[X.Y.Z]
• ☐ Resolve any conflicts (release-only fixes that are not yet in main)
• ☐ Delete the release branch after successful merge

Hotfix Process

When to use: P0 or P1 production issue requiring immediate fix.

git checkout release/v[X.Y.Z]   # or main, for trunk-based teams
git checkout -b hotfix/[ticket-id]-description
# ... fix the issue ...
git push origin hotfix/[ticket-id]-description
# Create PR to release branch AND main

• ☐ Hotfix branched from the current production release
• ☐ Expedited code review (minimum 1 approver)
• ☐ Hotfix merged to release branch and deployed to production
• ☐ Hotfix cherry-picked or merged to main within 24 hours
• ☐ Incident documented in post-mortem

Version Numbering

Example

Team: Platform | Model: Release branches | Cadence: Biweekly (per-sprint)

Current Release Cycle

Bugfixes on Release Branch

Active Hotfix

Tips

1. Keep release branches short-lived. A release branch should exist for 3-7 days maximum: just long enough for QA stabilization and deployment. Long-lived release branches diverge from main, creating painful merge conflicts. If stabilization takes longer than a week, your pre-release quality process needs improvement.

1. Feature branches should be small. A feature branch that lives for more than 3-5 days is a merge risk. Break features into smaller increments and merge to main frequently. Use feature toggles to hide incomplete work. The story splitting template helps decompose work into mergeable increments.

1. Automate what you can. Branch creation, environment deployment, and merge-back should be scripted or handled by CI/CD. The manual steps should be decisions (approve, sign off), not mechanics (create branch, run tests). See the Product Operations Handbook for building automated delivery pipelines.

1. Never commit directly to main or release branches. All changes go through pull requests, even hotfixes. The only exception is the initial release branch creation. This is not bureaucracy. It is how you maintain a clean history and prevent accidental breakage.

1. Document the model once, then enforce with automation. Branch protection rules, required reviewers, and CI checks should enforce the policies in this document automatically. If the document says "2 approvals required," configure GitHub/GitLab to block merges without 2 approvals. Documented policies that are not enforced are suggestions.