`git tag -l` Is the Command You Should Run When Release History Feels Hand-Wavy and You Need to See What Was Actually Cut
A practical guide to `git tag -l` for listing release tags so you can inspect what versions exist before checking out old code, building a hotfix, or pretending release history is obvious.
Why this command matters: release conversations get vague quickly when nobody checks what tags actually exist.
If you need to inspect an older release, compare version history, or answer “did we ever tag that?”, git tag -l is the simplest way to stop speaking in folklore.
The command
git tag -lYou can also filter:
git tag -l "v2.*"That is useful when a repo has a long tag history and you only care about a version family.
What it helps with
This command is especially useful when:
- preparing a hotfix from an old release line
- checking whether CI should build from a tag
- confirming a versioning convention is actually being followed
- finding which releases exist before checkout or diff work
It is a boring command with high decision value.
Final recommendation
When release history gets hand-wavy, run git tag -l and look at what is really there. Tags are one of the cleanest release anchors a repo has, so it makes sense to inspect them before building stories around version history.