If production is coughing and the users are texting angry emojis this is your emergency plan. A Gitflow hotfix branch gets a critical bug patched, keeps history readable and makes sure the same fix lands on the develop line without drama. This guide walks through the commands and the tiny bit of discipline required to avoid chaos.

When to use a hotfix branch

Hotfix branches are for urgent fixes that must reach production right away. Use them when you need a minimal, focused change to master or main in your Gitflow release process. If the problem can wait for the next sprint then use a normal feature or release branch instead.

Create the hotfix branch

Start from the production branch which is usually named master or main. Give the branch a clear name that starts with hotfix slash and a version number or short description so your teammates stop guessing what it does.

git checkout master
git pull origin master
git checkout -b hotfix/1.2.1

Apply the fix and commit

Make the smallest change that actually fixes the issue. Small focused commits are your friends because reviews and rollbacks are easier. Run a quick local test before you commit so you do not create more work for everyone else.

git add .
git commit -m 'Fix critical bug in payment flow'

Merge into production and tag the release

Merge the hotfix into production with a no fast forward merge to preserve a visible branch point in history. Then create an annotated tag for the hotfix release. After that merge the same hotfix into develop so the fix does not vanish when the next release ships.

git checkout master
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m 'Hotfix release 1.2.1'

git checkout develop
git merge --no-ff hotfix/1.2.1

If you hit merge conflicts when merging into develop handle them carefully. The production merge is the priority. Resolve conflicts, test, and keep commit messages clear so audit trails for version control stay sane.

Push changes and cleanup

Push the production branch and tags first so the fix is live on remote. Then push develop. Finally remove the remote hotfix branch to avoid branch soup.

git push origin master --tags
git push origin develop
git push origin --delete hotfix/1.2.1

Quick checklist before you merge

• Run a slim automated test suite on the hotfix branch
• Keep commits focused and message them clearly
• Use --no-ff merges to preserve the hotfix story in history
• Tag the release with an annotated tag for audits and rollbacks
• Merge the hotfix into develop to avoid regressions

Tips from the real world

If your repo loves merge noise consider a short policy about hotfix naming and tagging. If your team prefers a linear history then you can use a different merge strategy but be consistent. This is a practical git tutorial style workflow that keeps release tags clear and prevents hotfixes from getting lost in the branch forest.

Follow the steps and you will ship a hotfix that fixes the problem, keeps history readable and spares the team pointless mystery hunting later. Or at least you will look like you knew what you were doing while the users calm down.