Git Tags, Releases & Versioning
Git tags mark important points in history - typically production releases. Combined with Semantic Versioning (SemVer), tags power automated release pipelines.
Semantic Versioning (SemVer)
- Format: MAJOR.MINOR.PATCH (e.g., v2.1.3)
- MAJOR: Breaking changes that require code changes from consumers (v1.x.x → v2.0.0)
- MINOR: New backward-compatible features (v2.0.0 → v2.1.0)
- PATCH: Backward-compatible bug fixes (v2.1.0 → v2.1.1)
- Pre-release: v3.0.0-alpha.1, v3.0.0-beta.2, v3.0.0-rc.1
- Conventional Commits - drives semantic-release for automatic versioning: feat: = MINOR, fix: = PATCH, feat!: or BREAKING CHANGE: = MAJOR
Git Tags & GitHub Releases
# Create an annotated tag (preferred for releases)
git tag -a v2.1.0 -m "Release v2.1.0: add payment gateway"
# List all tags
git tag --sort=-version:refname
# Push a specific tag to remote
git push origin v2.1.0
# Push ALL tags
git push --tags
# Delete a tag (locally and remote)
git tag -d v2.0.0-beta
git push origin --delete v2.0.0-beta
# Checkout code at a specific tag (detached HEAD)
git checkout v1.5.2
# Automated versioning with semantic-release (CI/CD)
# package.json setup:
# {
# "release": {
# "branches": ["main"],
# "plugins": [
# "@semantic-release/commit-analyzer",
# "@semantic-release/release-notes-generator",
# "@semantic-release/github",
# "@semantic-release/npm"
# ]
# }
# }
# Every commit with conventional commit format:
# feat(auth): add OAuth2 login → bumps MINOR
# fix(api): correct null check → bumps PATCH
# feat!: redesign auth API → bumps MAJOR
#
# semantic-release runs in CI, creates tag + GitHub Release automaticallyQuick Quiz
Tip
Tip
Practice Git Tags Releases Versioning in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Choose based on team size, release cadence, and deployment model
Practice Task
Note
Practice Task - (1) Write a working example of Git Tags Releases Versioning from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Git Tags Releases Versioning is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready devops code.
Key Takeaways
- Git tags mark important points in history - typically production releases.
- Format: MAJOR.MINOR.PATCH (e.g., v2.1.3)
- MAJOR: Breaking changes that require code changes from consumers (v1.x.x → v2.0.0)
- MINOR: New backward-compatible features (v2.0.0 → v2.1.0)