Git Tags: Compare a Simple Commit Label with an Annotated Tag

Create a disposable snapshot

Use a new local practice repository with a small text file and one commit. Keep it separate from shared repositories. Record the commit ID first so the two tag types can be compared against exactly the same underlying snapshot.

Make two different tag forms

Create a new lightweight practice tag on that commit. Create another practice tag using git tag -a with a short explanatory message. The lightweight tag is a reference to an object, commonly the commit. The annotated tag introduces a tag object carrying its own metadata and target.

Inspect the object and the commit

Use git show for each tag and inspect the referenced object type when comparing them. For an annotated tag, distinguish the tag object ID from the underlying commit ID. Two labels can lead to the same commit while one also carries a separate metadata object.

Keep annotation and signing separate

An annotation is not automatically a cryptographic signature. A release process requiring signed tags needs an explicit signing and verification policy. Likewise, neither tag form proves that tests passed, a binary matches the source or a public website serves that revision.

Preserve shared release references

• Choose fresh practice names and keep this exercise local.
• Record the target commit and the reason for an annotation.
• Do not move, delete or force-push an existing team release tag.
• Treat build, deployment and live verification as separate observations.

Use the record in a release discussion

Save the tag inspection alongside the practice commit so another learner can repeat it. Git and release-workflow foundations fit the Mango Engineers DevOps path. The useful output is a precise explanation of what the label points to and what evidence it does, or does not, contain.