Tags & Releases — Milestone Sticky Notes

When the Campus Library team finishes a big milestone, the librarian doesn't want to hunt through the diary to remember which commit shipped. They stick a golden sticky note on that exact entry: a tag.

A tag is a permanent name attached to one commit — usually a release like v1.0.

Creating a Tag

Lightweight tag (just a name on a commit)

git tag v1.0

Annotated tag (a signed sticky note with a message — recommended)

git tag -a v1.0 -m "First release of Campus Library"

Remember

Prefer annotated tags (-a -m) for releases — they store who, when, and why, like a proper diary entry. Lightweight tags are fine for quick milestones.

Viewing Tags

List all tags

git tag

v1.0

See the details of a tag

git show v1.0

Tagging a Past Commit

Forgot to tag, and the release was two commits ago? Tag by hash — the librarian can stick the note on any past entry:

Tag an older commit

git tag -a v0.9 9b2c4d1 -m "Beta release"

Sharing Tags

Tags don't travel with git push automatically. Send them to the central library:

Push one tag

git push origin v1.0

Push all tags at once

git push origin --tags

Using a Tag

Travel to a release

git checkout v1.0

Remember

Tags are like branches that never move. A branch moves as you commit; a tag is fixed forever to one moment — the perfect anchor for "this is what we shipped."

Semantic Versioning — Reading v1.0.0

Versions follow a simple convention called semantic versioning:

Version	Bump when…	Example
Major	breaking change	1.0.0 → 2.0.0 (login flow completely changed)
Minor	new feature, still compatible	1.0.0 → 1.1.0 (added a search page)
Patch	bug fix only	1.0.0 → 1.0.1 (fixed a typo)

So v2.1.3 reads: 2nd big version, 1 new feature, 3 bug fixes.

Remember

Tag when it ships. git tag -a v1.0 -m "..." after every release means anyone can git checkout v1.0 and see exactly what customers were using.

Now try it for real in the Capstone — you'll tag Campus Library v1.0 at the end.