Tags, annotations and release naming

• Create an annotated tag with a deliberate message.
• Verify tag object and peeled commit separately.
• Push one explicit tag without all-tag publication.
• Keep tag creation distinct from a hosted release.

Start where lesson 13 ended: main/H7 clean, server main H7, feature published at F1; no v0.1.0 tag exists. Local demo tag signing is explicitly not requested.

The video was recorded with Git 2.52.0 and GitTree 2.0 on Ubuntu 24.04: the tag was created and pushed in the app; the before state, the refused duplicate name and the checks ran in the terminal. Nothing was run on macOS or Windows, and Ubuntu is the only Linux system recorded. GitTree's source Git floor is 2.39.0.

GitTree asks you to sign in; the Free plan then covers every step here. No provider account, Pro/trial, API credential or internet service is needed. A local bare origin is not GitLab or CI. All identities use example.com; never run this lesson inside a source checkout.

Make mutations through either GitTree or the native path at identical inputs, not both consecutively. Read-only verification can follow either. Any preparation described as terminal work is labeled native preparation, never an invented app feature.

A branch normally advances with commits; a release tag is a deliberately stable name. A lightweight tag names an object directly; an annotated tag adds its own tag object, tagger and message.

v0.1.0 names a tag object here. v0.1.0^{} peels it to the commit. Different object IDs for those two layers are expected and do not indicate two releases.

Annotation is not a cryptographic signature. Publishing a Git tag is not creating provider release notes, uploading assets or distributing a desktop release. None of those external actions is performed here.

Create adds refs/tags/v0.1.0 plus a tag object; push adds that selected server tag. HEAD, local branches, index and working files do not move.

Use original main after lesson 13. Inspect the actual H7 SHA and verify the tag is absent before creating it. Do not add a notebook commit after tagging.

Palette: Command+Shift+P (Ctrl+Shift+P on Ubuntu); type the exact named command and select it. Named-ref actions use that row's context menu, not an argument-free palette shortcut.

1. Select the actual main/H7 graph row (docs: add Leo's review reminder); confirm its footer change and identity, then right-click it.
2. Open Tag Here and choose Create Annotated Tag Here… (the row's menu also lists a plain Create Tag Here…, which makes a lightweight tag). The dialog is titled “Create an annotated tag at” the commit's short id.
3. Set Tag name v0.1.0 and Message First usable GitTree Features course checkpoint.
4. Under Signing the choices are Follow Git config, Sign this tag and Don’t sign this tag; the dialog notes that Git config does not sign tags (tag.gpgSign is not set). Select Don’t sign this tag for this explicit unsigned lesson; do not change global signing config.
5. Click Create Tag once and wait; confirm v0.1.0 labels the intended commit without changing checkout.
6. In the side panel's Tags group, right-click v0.1.0 → Push Tag (the same menu also offers Delete Tag… and Delete Tag from Remote…, which this lesson does not use). The notice reads “Pushed tag v0.1.0.”
7. Verify native tag object type, message and peeled commit plus server tag identity; do not confuse annotation with signing.
8. Leave main clean and the tag unchanged. Do not use Push All Tags or create a provider release.

For every ordinary commit: Summary is the stated subject; Description empty; Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit and Allow Empty Commit off; no co-authors. Stage only the named files, then Commit Changes to N Files once (File for one), or Command+Enter as an alternative. Wait for the real result. A lesson that explicitly amends changes only that stated option.

Native equivalent at clean main:

git tag --annotate --no-sign v0.1.0 --message "First usable GitTree Features course checkpoint"
git cat-file -t v0.1.0
git for-each-ref --format='%(contents:subject)' refs/tags/v0.1.0
git rev-parse 'v0.1.0^{}'
git push --quiet origin refs/tags/v0.1.0
git ls-remote --tags origin refs/tags/v0.1.0 'refs/tags/v0.1.0^{}'
git status --short

--annotate has the short form -a (git tag -a v0.1.0 -m "message"), and --message is -m; either way Git stores a tag object with its own message, unlike the lightweight git tag v0.1.0.

Create/push succeed; type and message output:

tag
First usable GitTree Features course checkpoint

The peeled SHA equals actual main. ls-remote returns actual tag-object and peeled-commit IDs; record these variable values, not model labels. Final status is empty. Separate duplicate-name attempt:

git tag v0.1.0

Actual stderr, exit 128:

fatal: tag 'v0.1.0' already exists

The original tag remains; never use -f to conceal the collision.

Where you end: Annotated v0.1.0 exists locally and on the local bare origin, message First usable GitTree Features course checkpoint, peeled commit H7. Main/HEAD/index/work unchanged; no hosted release or signature claimed.

• Calling an annotated tag signed.
• Tagging the selected old row instead of main.
• Pushing every local tag unintentionally.

Cancel a wrong creation before confirming. If a local tag is wrong, inspect its actual target and whether it was published before any explicit deletion; native duplicate refusal preserves the existing ref.

Answer each question, then read why. Questions marked “Required” count toward completing the lesson.

1. Question 1 of 6

   Question 1 of 6

   What is v0.1.0 here?

   Choose one answer.

   A moving branch

   A hosted asset upload

   An annotated tag object

   Check answer
2. Question 2 of 6

   Question 2 of 6

   Which claims are justified?

   Choose every answer that applies.

   Annotation has a message

   Annotation proves signature

   HEAD stays unchanged

   Check answer
3. Question 3 of 6

   Question 3 of 6Required

   Does tagging create another main commit?

   Choose one answer.

   No

   Yes, merge commit

   Only if pushed

   Check answer
4. Question 4 of 6

   Question 4 of 6Required

   Reuse the same name without force: result?

   Choose one answer.

   Automatic signature

   Silent replacement

   Refusal, existing tag retained

   Check answer
5. Question 5 of 6

   Question 5 of 6

   Tag and main IDs differ: corrupt?

   Choose one answer.

   Always corrupt

   Must delete main

   Not necessarily; peel it

   Check answer
6. Question 6 of 6

   Question 6 of 6Required

   What proves the result?

   Choose every answer that applies.

   Type, message and peeled-main equality

   Release page alone

   Server tag identities match local ones

   Check answer

Verify object type tag, exact annotation, peeled SHA=main and both server tag layers. Predict duplicate refusal while preserving the first tag and clean work.

• Annotation adds a tag object.
• Push only the chosen tag.
• Git tags and hosted releases differ.

• Push commits and publish a branch (lesson 13)
• Read history without moving HEAD (lesson 8)
• Download GitTree

Annotated tag — وسم مشروح; lightweight tag — وسم خفيف; tagger — منشئ الوسم; peeled commit — الإيداع المحسوم.