Hone

Lessons · Git · naming a commit for good

Marking a release

A tag is a fixed label on one commit. Unlike a branch it never moves, which is what makes it right for releases: v1.0 always means that commit.

Hone is a place to practise programming. This is one of its lessons, written out in full and free to read without an account.

What it is for

Deploy v1.4, reproduce the bug a customer saw on v1.3, diff two releases: tags make versions addressable long after the branches are gone.

How to think about it

Tag the commit you actually released, with an annotated tag (-a) that carries a message and a date. Push tags explicitly; they do not travel with git push by default.

Worked example

git tag v1.0
A fixed label on the current commit.
git tag
Lists tags.
git tag -a v1.1 -m "Release 1.1"
An annotated tag carries a message, author and date: use it for releases.
git push origin v1.1
Tags are not pushed by default; send them by name, or all with --tags.

Your turn

Make an annotated release tag.

git tag  v2.0 -m "Release 2.0"

The trap

A tag does not move. Tagging the wrong commit and re-tagging needs -f and confuses everyone who fetched the old one; check git log first.

Practise naming a commit for good on HoneA question on it now, a coding challenge where there is one, and it is remembered for review. Free, no email needed.