Hey devs 👋! Ever been in a situation where someone on your team (maybe even you 👀) asks:

"Hey... which commit did we deploy to production last week?"

And suddenly everyone's scrolling through the Git history, trying to decipher commit messages like "final-final-really-final-fix" or "hotfix2attempt3"? Yeah. We’ve all been there. It's like trying to find a needle in a haystack—except the haystack is on fire and you’re out of coffee.

But what if I told you there’s a super simple way to avoid all that? Let me introduce you to one of the most underused but incredibly powerful features of Git: tags.

The Problem: "What Commit Did We Ship?"

Let’s set the scene.
You’re working on a product. Releases are flying out the door. The PM pings you:

"The client says version 2.1.0 had a bug. Can we roll back to it?"

Panic sets in. Your Git history is a mess. There’s no clear signpost telling you what commit represented version 2.1.0.

You wish you could just mark important commits.

Well... you can. That’s exactly what Git tags are for.

So What Exactly Are Git Tags?

Think of tags like bookmarks or sticky notes on your Git timeline. They let you say: “Hey, this commit right here? This is version 1.0.”

Once a tag is created, it’s permanently attached to a specific commit. It won’t move or change even as new commits get added. This makes it perfect for marking release points.

Quick Example: Tagging a Release

Let’s say you just finished testing and everything’s good to go for version 2.1.0. Here's how you tag it:

git tag -a v2.1.0 -m "Release version 2.1.0"
git push origin v2.1.0

Now, any time someone wants to check out that version:

git checkout v2.1.0

Boom. You’re in the exact state the code was when it shipped.

Lightweight vs Annotated Tags

There are two types of tags in Git:

1. Lightweight Tags

  • Just a name pointing to a commit.
  • No extra info.
  • Example: 
git tag v2.2.0

2. Annotated Tags

  • Full metadata: tagger name, date, message.
  • Stored as full Git objects.
  • Recommended for releases. 
git tag -a v2.2.0 -m "Added dark mode support"

Pro Moves: Tags + CI/CD

Tags are amazing when combined with continuous deployment.

Want to deploy only when a new version is tagged? Easy.
Many CI/CD tools let you set triggers like:

"Deploy when a new tag matching v* is pushed."

That means your pipeline only fires when a proper version tag goes out. Clean, intentional, and no surprises.

Git Tag Cheat Sheet 🧠

Command What It Does
git tag List all tags
git tag -a v1.0 -m "Message" Create annotated tag
git tag v1.0 Create lightweight tag
git push origin v1.0 Push a single tag
git push origin --tags Push all tags
git show v1.0 Show tag details
git tag -d v1.0 Delete local tag
git push origin :refs/tags/v1.0 Delete remote tag

Friendly Reminder: Semantic Versioning Exists for a Reason

Stick to semantic versioning when tagging:

vMAJOR.MINOR.PATCH

Examples:

  • v1.0.0: First release
  • v2.1.0: Minor update (new features)
  • v2.1.1: Patch fix

This helps your team (and your future self) understand what changed at a glance.

TL;DR — Why You Should Care

Git tags:

  • ✅ Mark important commits like releases
  • ✅ Help you roll back or reproduce past states
  • ✅ Play nicely with CI/CD
  • ✅ Keep you sane when debugging or tracing

If you're not tagging your releases yet, give it a shot. Start small. Next time you ship something, tag it. You’ll thank yourself later.

Got a tagging tip? A tagging horror story? Or just a question? Hit me up in the comments 💬

Happy tagging, folks!

✌️