Understanding Semantic Versioning and Its Importance in Git Branching Models

In the previous post on Git branching models, tags came up as the way to mark a commit as a release. Semantic Versioning is the standard for what those tags should actually say.

What is Semantic Versioning?

SemVer version numbers follow the format MAJOR.MINOR.PATCH:

• MAJOR — breaking changes. Something that worked before might not work after. Users need to take action when upgrading.
• MINOR — new functionality, backward-compatible. Users can upgrade safely and get new features.
• PATCH — bug fixes, backward-compatible. Safe to update, nothing new.

Pre-release versions extend the format: 1.0.0-alpha, 1.0.0-beta.2. Build metadata can be appended: 1.0.0+20130313.

One important principle: a released version is immutable. Once 2.3.4 ships, it doesn’t change. If something needs fixing, that’s 2.3.5. This makes every version a reliable snapshot you can reference, roll back to, or pin as a dependency.

How this connects to Git tags

When code merges into master and is ready to release, the version number in the tag tells users what kind of change they’re getting:

Change	Old version	New tag
Bug fix in auth flow	2.3.4	2.3.5
New search feature	2.3.5	2.4.0
Breaking API change	2.4.0	3.0.0

This matters most for libraries and packages, where downstream consumers are making upgrade decisions based on your version number. But even for internal tools and services, consistent versioning gives your team a shared language for talking about what changed and how risky an upgrade is.

In practice

Most teams automate version bumping and tagging in CI. A conventional commit message format (feat:, fix:, chore:) lets tools like semantic-release determine the right version increment automatically. You ship, the pipeline tags, no manual decisions needed.

The combination of a clean branching model and SemVer tags means every release has a clear lineage: which PR merged it, what changed, and what to roll back to if something goes wrong.