Git release workflow: tags, changelogs, hotfixes, and safe revert

Releases need more than merging to main#

Once real users depend on a product, you need to know which release is running, which changes it contains, how hotfixes move, and which commit to revert if production fails.

Tag release commits#

Tags give a stable name to release commits. Use annotated tags for official releases because they include metadata and a message.

git tag -a v1.4.2 -m "Release v1.4.2"
git push origin v1.4.2

Write changelogs for readers#

A changelog should group impact, not dump raw commits. Useful sections include Added, Changed, Fixed, Security, Migration, Deprecated, and Removed.

Hotfix and revert#

A hotfix should be short but still controlled: branch from the production commit, fix, test the relevant path, tag a new release, and merge the fix back so main does not drift.

For changes already shared or deployed, git revert is usually safer than rewriting history because it creates a new commit that reverses the change.

Release checklist#

• Main or the release branch clearly reflects deployable state.
• Every release maps to a tag or build number.
• Changelog describes user and operational impact.
• Hotfixes go through Git, not direct server edits.
• Revert is preferred over history rewriting for public changes.

Primary references#

• Git Docs: git tag
• Git Docs: git revert
• Git Docs: git merge