For marking a release in Git, what does an annotated tag give you that a lightweight tag does not?

## Two things wearing the same name Git calls both of these a "tag", but they are different constructions. A **lightweight tag** is nothing more than a ref: a name under `refs/tags/` whose value is an object id, usually a commit's. Creating one (`git tag v1.4.0`) writes no new object at all. It is the tag equivalent of a branch that never moves. An **annotated tag** (`git tag -a v1.4.0 -m "Release 1.4.0"`) creates a fourth kind of Git object — alongside blobs, trees and commits — called a *tag object*. That object stores the id and type of the thing being tagged, the tag name, a *tagger* identity line (name, email, timestamp) and a message. The ref under `refs/tags/` then points at the tag object, which in turn points at the commit. `git tag -s` (or `tag.gpgSign`/`-a` with signing configured) appends a cryptographic signature over that object's contents, and `git tag -v` verifies it. The cheapest way to see which you have: `git cat-file -t v1.4.0` prints `tag` for an annotated tag and `commit` for a lightweight one. `git show v1.4.0` on an annotated tag prints the tagger block and message before the commit; on a lightweight tag it goes straight to the commit. ## Why the distinction matters for a release **Provenance.** A release tag is a claim: *this exact tree is what we shipped as 1.4.0*. An annotated tag records who made that claim and when, independently of the commit's author and commit dates — which are often someone else's, and often days earlier. When a signature is attached, the claim becomes verifiable rather than merely asserted. **Release notes.** The tag message is a natural home for the short "what's in this release" text, and it lives in the repository rather than in an external system. `git tag -n<n>` lists tags with the first *n* lines of their messages; a lightweight tag shows the commit subject instead, which is usually some unrelated bug fix that happened to be at the tip. **`git describe`.** By default `git describe` walks back for the nearest **annotated** tag; lightweight tags are ignored unless you pass `--tags`. Build systems that stamp a version by calling `git describe` therefore silently disagree with a repository that uses lightweight tags — either producing a stale version from an older annotated tag or failing outright when none exists. **Publication.** `git push --follow-tags` pushes annotated tags reachable from the pushed commits and skips lightweight ones entirely. If your release tags are lightweight, the ergonomic push flow does not carry them, and people fall back to `git push --tags`, which sprays every local bookmark onto the shared remote. **Sorting and tooling.** Both kinds sort with `git tag --sort=-v:refname` (version-aware ordering, so `v1.10.0` sorts above `v1.9.0`), and both work with `git tag --contains <commit>` to answer "which releases include this fix". Those capabilities are not a reason to choose one over the other — the differentiators are metadata, `describe`, signing and push behaviour. ## Where lightweight tags are genuinely fine As private, throwaway markers: `git tag before-rebase` so you can find a commit again, a temporary label while bisecting by hand, a local pin on a state you want to compare against. They cost nothing, carry no ceremony, and you delete them with `git tag -d`. The rule of thumb interviewers want to hear: **annotated for anything you publish, lightweight for anything you would be happy to lose.** ## Practical mechanics Tag the exact commit you verified, not "whatever HEAD is now" — `git tag -a v1.4.0 -m "..." <commit>` takes an explicit commit, which matters when the release branch has moved since the build. Editing a tag is not a thing: `git tag -f` deletes and recreates the ref, and since fetch will not overwrite an existing tag in other clones, a moved published tag diverges silently across machines. If a published tag is wrong, publish a corrected one under a new name. A useful mental check for the interview: a lightweight tag adds a *name*; an annotated tag adds a *record*. Releases need the record. ## What an interviewer probes next Usually one of three things: how you would tell the two apart in an unfamiliar repository (`git cat-file -t`, or `git for-each-ref refs/tags` showing objecttype), why `git describe` came back with an unexpected version (lightweight tags being skipped), or how signing turns the tag into something a downstream consumer can verify rather than trust.