Before this lesson

Understand commit identifiers and branches. This tag exercise does not publish a real release.

Use Git 2.35+ and a Bash-compatible terminal, such as Git Bash on Windows. Each complete example creates an independent temporary directory. Run it only in that practice repository. Configuration is repository-local and uses a practice identity. Temporary directories are not automatically removed; clean them up after finishing.

What you will be able to do

Tag a verified commit and distinguish tags from moving branches.

Understand the mechanism

Branches normally move with new commits, while tags give historical objects stable names. Lightweight tags are simple references; annotated tags also record a message and tagger metadata, useful for release context.

A tag does not prove testing passed. Check the worktree and test results before tagging the intended commit. Names such as v1.0.0 are conventions and should reflect real compatibility changes.

A branch push does not necessarily upload every tag; push the intended tag explicitly. Avoid moving shared release tags, which could make one name refer to different content for different users.

Runnable example

lab=$(mktemp -d)
cd "$lab"
git init -b main .
git config user.name "Honeysuck Learner"
git config user.email 'learner'@'example.invalid'
git config commit.gpgsign false
git config core.autocrlf false
printf 'Start learning\n' > notes.txt
git add notes.txt
git commit -m "Start learning notes"
git tag -a v1.0.0 -m "First verified notebook"
printf 'Next version draft\n' >> notes.txt
git add notes.txt
git commit -m "Continue after first release"
git tag --list
git show v1.0.0:notes.txt
git log -1 --format=%s 'v1.0.0^{commit}'
git log -1 --format=%s HEAD
git diff v1.0.0 HEAD -- notes.txt

Trace and verify

v1.0.0 still identifies Start learning notes and its file contains only Start learning. main has advanced to Continue after first release, and the diff shows the draft.

Common mistakes and boundaries

Checking out a tag directly can detach HEAD. Create a branch for a fix, for example git switch -c fix/v1 v1.0.0, before continuing development.

Practice challenge

Create fix/v1 from v1.0.0 and verify that the later draft is absent.

Reference solution and reasoning

Run git switch -c fix/v1 v1.0.0. notes.txt contains only Start learning. Later main commits remain available when switching back.

Further reading