Git Cheatsheet
Tags
Use this Git reference while you build software engineering projects, review code for technical interview prep, or polish examples for a software engineer resume.
Tag Types
| Type | Description | Has message/metadata? |
|---|---|---|
| Lightweight | Just a named pointer to a commit | No |
| Annotated | Full Git object with tagger, date, message, optional GPG signature | Yes |
Prefer annotated tags for releases — they carry metadata and can be GPG-signed.
Checking Out a Tag
Checking out a tag puts you in detached HEAD state:
git checkout v1.0.0 # Detached HEAD at the tagged commit git switch --detach v1.0.0 # Modern equivalent # If you want to make commits from this point: git checkout -b release/v1.0.0 v1.0.0 # Create a branch from the tag git switch -c release/v1.0.0 v1.0.0 # Modern equivalent
Re-Tagging (Moving a Tag)
Tags are immutable by convention, but you can force-overwrite:
git tag -f v1.0.0 <sha> # Move tag to a new commit (local) git push --force origin v1.0.0 # Force-push updated tag (requires coordination)
Moving a published tag breaks everyone who has already fetched it. Communicate clearly or create a new tag instead (e.g.,
v1.0.1).
Semantic Versioning Convention
# Format: vMAJOR.MINOR.PATCH[-prerelease][+build] git tag -a v1.0.0 -m "Initial stable release" git tag -a v1.1.0 -m "Add feature X" git tag -a v1.1.1 -m "Fix bug Y" git tag -a v2.0.0 -m "Breaking API change" git tag -a v2.0.0-rc.1 -m "Release candidate 1" git tag -a v2.0.0-beta.2 -m "Beta 2"
git describe
git describe # e.g., "v1.0.0-14-gabcdef0" (tag-commits-sha) git describe --tags # Use any tag (including lightweight) git describe --always # Fall back to SHA if no tag found git describe --match "v[0-9]*" # Only match version tags git describe HEAD~5 # Describe a specific commit
Output format: <tag>-<commits-since>-g<sha>
- v1.0.0 — exactly on tag
- v1.0.0-14-gabcdef0 — 14 commits after v1.0.0, at commit abcdef0