Start the hotfix branch from the exact release tag that is running in production, not from main, unless production already is main. That keeps unreviewed feature work out of an urgent fix. Land the same fix on main as well, so the next release does not bring the vulnerability back.
Why the starting point matters
A hotfix has one job: change as little as possible between what customers run today and what they run after the fix. Main usually holds weeks of unreleased work. If you branch from it, your hotfix ships all of that too, and you can no longer say what changed.
The Git project's own workflow notes describe the same idea. They keep a maintenance branch for fixes to a released version, separate from the branch where new features land, and they describe copying that branch to a version named branch when a newer feature release ships so the older release can still receive fixes.
Decision table
| Your situation | Branch from | Why |
|---|---|---|
| Deploy from main many times a day | main | Production is main, so a small commit is the hotfix |
| One release line, deployed in batches | The release tag in production | Keeps unreleased work out |
| Several supported release lines | The tag of each affected line | Each line needs its own tested fix |
| Hosted product with a release branch | The release branch head | It matches what was last built |
Steps for a tagged release
- Identify the exact tag running in production. Check the deployed artifact, not your memory.
- Create a branch from that tag, named so people can see its purpose, for example hotfix/2.4.1-input-validation.
- Write the smallest fix that closes the problem, plus a test that fails without it.
- Run the pipeline you normally run. A hotfix is not a reason to skip the vulnerability scan or the review.
- Tag the result with the next patch version and release it.
- Open a second change that brings the same fix to main.
git checkout -b hotfix/2.4.1-input-validation v2.4.0
# make the fix and test
git commit -am "Reject oversized path segments"
git tag v2.4.1
Fix on main first when you can
When time allows, fix main first and then copy the commit to the older branch with a cherry-pick. This is called upstream first, and it prevents the classic regression where version 2.4.1 is fixed and 2.5.0 is not. The Linux kernel stable rules require that a fix, or an equivalent, already exist in mainline before it is accepted into a stable tree, for the same reason.
When the situation is urgent and main has diverged too far, fix the old branch first and open the main change within the same working day. Put a link to each change in the other.
Common mistakes
- Branching from main because it is the default and shipping untested features.
- Forgetting the forward change, so the next release reintroduces the bug.
- Building the hotfix on a different toolchain version than the original release.
- Skipping the tag, which leaves production running a commit nobody can name.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate evaluates the change before merge, which is the check a hotfix branch should still pass.
Safeguard can run dependency scanning and policy gates on every pull request, including the ones on hotfix branches, and its autonomous remediation can open fix PRs when you turn it on (it is off by default). You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can I branch from main if I deploy continuously?
Yes. If every merge to main goes to production, main is the release. Keep the fix small and ship it like any other change.
Do I need a tag if the fix is urgent?
Yes. A tag is how you later prove which code ran in production and which fix it contained.
Sources
Last reviewed: 19 October 2026.
