Release Branch Management Template

Trunk-based development (everything on main, deploy from tagged commits) is faster and simpler but requires strong CI/CD, feature toggles, and high test coverage. Release branches add a stabilization phase that gives QA time to test without blocking new feature development on main. Teams deploying daily or more usually prefer trunk-based. Teams deploying weekly or per-sprint benefit from release branches.

If you have a release branch in stabilization and need to start the next sprint's features, those features go on main as usual. The next release branch will be cut from main after the current release ships. Avoid having more than one release branch active at a time unless you are maintaining multiple product versions.

Apply the hotfix to the release branch first (fix production), then merge or cherry-pick to main. If there is a conflict, resolve it on main. The production fix takes priority. Do not delay the hotfix to avoid a merge conflict.

PMs do not need to manage branches, but they should understand the model well enough to answer: "When will this feature be available in staging? When will it ship to production?" The release process timeline in this document gives PMs the information they need for stakeholder communication.