If releases had a VIP room it would be the release branch. Use Gitflow release branches to isolate final polish and version bumps from the chaos that is ongoing feature work. This keeps master pristine for production and develop sane for new work. Expect tests to be your best friend and CI to be the unforgiving bouncer.

Create the release branch

When develop is stable and feature work is wrapped up make a release branch. Pick a clear name that follows semantic versioning so humans and tools are both happy. For example use release/1.2.0 for a release at version 1.2.0.

git checkout -b release/1.2.0 develop

This isolates stabilization work so feature branches can keep flowing without sneaking into the final artifact.

Prepare version and run tests

Bump the version in the files your project actually cares about. Update package manifests build files or any other source of truth. Run the test suite locally and then let CI run the full pipeline. A green CI build reduces surprise incidents which nobody likes on release day.

git add package.json
git commit -m "Bump version to 1.2.0"
# run local tests and push the branch to trigger CI
git push origin release/1.2.0

Fix release bugs on the release branch

If testing finds bugs fix them directly on the release branch. Keep commits focused on stabilization. Do not merge experimental or half finished features into this branch. If production needs an urgent fix instead of waiting for the release follow the hotfix workflow on master and then merge that fix back into develop and any active release branches.

Merge the release into master and tag the release

Once QA and CI approve the release merge it into master and tag the exact commit that shipped. Tags are the lovely breadcrumb trail that makes rollbacks and audits less miserable.

git checkout master
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin master --tags

Merge back into develop and clean up

Bring version bumps and any stabilization commits back into develop so the work is synchronized. Then delete the release branch to keep your branch list tidy and signal that the release window is closed.

git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0
git push origin --delete release/1.2.0

Quick checklist

• Create release branch from develop when feature work is stable
• Bump semantic version numbers and run full test suite
• Fix release only bugs on the release branch
• Merge into master and tag the release commit
• Merge back into develop and delete the release branch

Common gotchas and tips

• Keep the release branch focused on stabilization work only. If it smells like a feature it probably is a feature.
• Let CI be the final judge. A green build is not a promise but it is a very good signal.
• Use clear tag names like v1.2.0 so rollbacks and audits do not require a séance.
• Communicate the release window to the team to avoid surprise merges into develop that then need awkward reconciliations.

This workflow keeps branching neat while supporting semantic versioning continuous integration and sane rollouts. Follow these steps and your releases will be predictable enough to plan around and messy enough to keep life interesting.