Release branches, hotfixes and tags
A release branch holds exactly what production runs, and a tag marks each released version. An urgent fix starts from that tag on a hotfix branch, is released with a new tag, and is then merged back into main so the next release keeps it. Published tags are never moved.
Who holds what
| Branch or tag | Holds | Changes by |
|---|---|---|
| main | the next release, being built and tested | reviewed pull requests |
| release/2.3 | what production runs for release 2.3 | fixes only |
| feature/* | one change in progress | its author |
| hotfix/* | one urgent fix for production | the fixer, then a review |
| v2.3.0, v2.3.1 | one released version each | never: a tag does not move |
Tags
A tag gives a commit a name that, by convention, never moves once published. A lightweight tag is just a name. An annotated tag, made with git tag -a v2.3.1 -m "...", also records who tagged it, when, and a message, which is why annotated tags are the ones meant for releases. Tags are pushed explicitly: git push origin v2.3.1 (or --tags for all of them).
Once a tag is published, people and tools rely on it. If it was put on the wrong commit, do not move it: release a new version with a new tag.
An urgent fix, step by step
$ git switch -c hotfix/2.3.1 v2.3.0 # start from exactly what production runs (fix jcl/PAYDAILY.jcl, review the diff) $ git commit -am "Hotfix: PAYDAILY reads the 2026 tax table" $ git switch release/2.3 $ git merge hotfix/2.3.1 $ git tag -a v2.3.1 -m "Hotfix 2.3.1: 2026 tax table" $ git push origin release/2.3 v2.3.1 $ git switch main $ git merge hotfix/2.3.1 # or the next release brings the bug back $ git push origin main
A hotfix branch starts from the tag, not from main, because main already holds unreleased work. Starting from the tag means production gains the fix and nothing else. Many teams send the hotfix through a pull request too; the review is short because the change is small.
Version numbers
Many teams number releases MAJOR.MINOR.PATCH: 2.3.0 is the 2.3 release, 2.3.1 the first fix to it, and 2.4.0 the next feature release. Whatever scheme your team uses, the release branch and its tags must let anyone answer "what exactly is running in production?" in one command: git show v2.3.1.
Which command creates a branch called hotfix/2.3.1 starting at tag v2.3.0 and switches to it?
Show a hint
git switch -c, the branch name, then the start point.
Show the solution
git switch -c hotfix/2.3.1 v2.3.0.
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
main holds work that is not released. Start from the release tag so production gains only the fix.
Others already have the old tag. Release a new version with a new tag instead.
The next release is built from main and would bring the bug back.
What you will see at work
- Release managers usually create the release branch and tags, and the pipeline deploys from a tag rather than from a branch tip.
- Hotfixes often come with an emergency change record; the tag name goes into it so auditors can find the exact code.
- When you are asked what is in production, answer with the tag and git log, not with a memory of what was merged.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.