Module 6: Release Engineering with Git

Annotated Tags, Signed Tags, and Version Markers

Module: Module 6: Release Engineering with Git

Tags give stable names to specific commits. Release engineering depends on being able to answer exactly what code shipped, which commit produced an artifact, and how to reproduce it.

Annotated tags are full Git objects with tagger metadata and a message. Lightweight tags are just refs. For releases, annotated tags are usually better because they carry context. Signed tags add cryptographic verification when your team requires stronger provenance.

Treat release tags as immutable. Moving a published tag creates confusion because different machines may disagree about what v1.2.0 means. If a release is wrong, ship v1.2.1 rather than rewriting what v1.2.0 pointed to.

Command Walkthrough

git tag -a v1.1.0 -m 'Release v1.1.0'
git tag
git show v1.1.0
git push origin v1.1.0
git tag -s v1.1.1 -m 'Release v1.1.1'
git tag -v v1.1.1

Representative output

commit d4e5f6a7b8c9
Author: Alex Engineer <[email protected]>

    Add focused change

 app.conf | 2 +-

Hands-on Lab

Tag the current practice project as v1.1.0, create one patch commit, then tag v1.1.1. Use git diff v1.1.0..v1.1.1 to inspect release contents.

What to Watch For

Do not move public tags unless the team has a documented incident process.
A tag does not deploy anything by itself. CI/CD policy decides what tags trigger.
Signed tags require key management. A broken signing setup can block release work.

Completion Check

You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.