Marker Beacons

Marking Important Moments

Tags are marker beacons in your history. While branches move as you commit, a tag stays fixed on one commit until you deliberately move or delete it—perfect for marking releases like v1.0.0 or other milestones.

Two Kinds of Tags

• Lightweight tags: A simple name pointing at a commit
• Annotated tags: Full objects with the tagger's name, date, and a message—recommended for releases

Creating Tags

# Lightweight tag
git tag v1.0.0

# Annotated tag (recommended)
git tag -a v1.0.0 -m "First stable release"

Tagging a Past Commit

git tag -a v0.9.0 abc123 -m "Beta release"

Forgot to tag a release? Tag any commit in your history by its hash.

Listing and Inspecting Tags

git tag                 # List all tags
git tag -l "v1.*"       # Filter with a pattern
git show v1.0.0         # See the tagged commit and message

Pushing Tags

Tags are not pushed automatically with git push:

git push origin v1.0.0    # Push one tag
git push origin --tags    # Push all tags

Deleting Tags

git tag -d v1.0.0                  # Delete locally
git push origin --delete v1.0.0   # Delete on the remote

Checking Out a Tag

git switch --detach v1.0.0

This puts you in a detached HEAD state—great for inspecting a release. To make changes from a tag, create a branch: git switch -c hotfix-1.0.1 v1.0.0.

Semantic Versioning

Most projects tag releases using semantic versioning: vMAJOR.MINOR.PATCH

• MAJOR: Breaking changes (v2.0.0)
• MINOR: New features, backward compatible (v1.1.0)
• PATCH: Bug fixes (v1.0.1)

On GitHub, tags power the Releases feature—each release is built on a tag, with release notes and downloadable assets.

Best Practices

• Always prefer annotated tags for releases—lightweight tags carry no author, date, or message
• Tag from a clean, tested commit on your main branch, never from a branch you might rebase later
• Adopt semantic versioning early; retrofitting a numbering scheme onto an existing project is painful

Next: Ship Replication

Deep space operations complete! You can merge, resolve conflicts, rebase, cherry-pick, stash, and tag. Next phase: multi-crew missions, starting with forking repositories.