Use Cases

  • Projects with regular release schedules but not needing Gitflow's full branch taxonomy
  • When release preparation requires stabilization time (bug fixes, docs, version bumps)
  • Organizations that want Gitflow's release discipline without the feature/* and hotfix/* overhead
  • Projects with versioned releases and changelogs that must be maintained

Components

  • main (main-branch): Production code representing released versions. Only receives merges from release branches. Every commit on main corresponds to a tagged release.
  • develop (main-branch): Integration branch for ongoing development. Features merge here; release branches are cut from here.
  • release branches (supporting-branch): Created from develop when a release is ready to stabilize. Only bug fixes, version bumps, and changelog updates happen here — no new features.
  • feature branches (supporting-branch): Informal branches for features — unlike Gitflow, strict feature/* naming is not required. Workflow is simpler for day-to-day development.

Steps

  1. Step 1: Create feature branch: Branch from develop to start new feature work
  2. Step 2: Develop feature: Commit to feature branch
  3. Step 3: Merge to develop: Merge completed features to develop
  4. Step 4: Create release branch: When develop is ready for release, create release branch
  5. Step 5: Prepare release: Stabilize release (bump version, update docs, fix bugs)
  6. Step 6: Merge to main: Merge release to main and tag version
  7. Step 7: Merge back to develop: Merge release back to develop to propagate fixes

Workflow Diagram

gitGraph commit id: "dev" branch develop checkout develop commit id: "feature" commit id: "feature2" checkout develop branch release checkout release commit id: "release prep" checkout main merge release tag: "v1.0" checkout develop merge release
Step 1 of —

Common Gotchas

  • Release branch management: Must merge release to both main AND develop. Missing the develop merge-back means bug fixes in the release branch silently disappear from the next development cycle. important
  • Features must be ready before the release branch is cut: Once a release branch is created, no new features can be added — only bug fixes. Features not yet merged to develop miss the release. important
  • Parallel release branches: Maintaining release/1.1 while release/1.2 is already open creates complex criss-cross merge scenarios. Limit to one active release branch at a time when possible. mild
  • Hotfix gap: Unlike Gitflow, this workflow has no hotfix/* branch type. Emergency production fixes are typically patched directly on a release or main branch and manually merged back to develop, which is error-prone. mild

Best Practices

  • Plan and communicate feature freeze dates so all features land in develop before the release branch is cut
  • Use semantic versioning (SemVer) and tag every commit on main with a version number
  • Automate release branch merge-back to develop in CI to prevent forgotten merges
  • Protect develop and main with branch rules requiring reviews and CI checks
  • Keep release branches short-lived — stabilize quickly and ship, then delete
  • Document release notes in the release branch before merging to main

Pros and Cons

Pros

  • Clear release preparation process with a dedicated stabilization period
  • Simpler than full Gitflow — no strict hotfix/* or feature/* branch taxonomy required
  • Supports versioned releases with tagged commits on main
  • Allows new feature development to continue on develop while a release stabilizes
  • Good middle ground between the simplicity of GitHub Flow and the rigidity of Gitflow

Cons

  • More complex than GitHub Flow or Feature Branch workflow
  • Release branches require active management (merge-back is error-prone if not automated)
  • Slower feature integration to production compared to continuous deployment models
  • No dedicated hotfix process — production fixes are ad-hoc
  • Not ideal for continuous deployment teams where every commit should be shippable

Real-World Examples

  • Microsoft Azure DevOps: Microsoft's "Release Flow" (used for Azure DevOps and Visual Studio) is a variant of this model. Teams cut a release branch from main, deploy it to production rings, and cherry-pick hot fixes to the release branch. They published a blog post in 2018 describing the model explicitly as an evolution away from Gitflow.
  • Node.js: The Node.js project maintains active release branches for multiple LTS (long-term support) lines (e.g., v18.x, v20.x). Features land in main, and release branches receive only bug fixes and security patches, following a model structurally identical to Release Branch workflow.
  • npm packages and libraries: Many widely-used npm packages use release branches to maintain a "next" development stream on develop while the current stable version is on main. This lets maintainers accept PRs for future versions without disrupting current users.