Mark important commits with tags

Branches usually move as work continues. A release marker should normally keep naming the same historical commit.

What you’ll learn

Create and inspect tags.
Distinguish annotated and lightweight tags.
Relate tags to versioned releases.

Branches move; release tags usually stay

1
Commit
Choose a tested historical point.
```
C7
```
→2
Tag
Attach a version name.
```
v1.0.0
```
→3
Publish
Optionally push the tag or create a hosted release.
```
shared version marker
```

shared version marker

Tags name important points in history

A tag is a reference commonly used for versions such as v1.0.0. An annotated tag stores additional tag metadata and a message; a lightweight tag is a simpler reference.

Creating a local tag does not automatically send it to a remote. Tags can be pushed explicitly, and teams should avoid moving published version tags without a strong coordinated reason.

Create an annotated release tag

Run this in a disposable practice repository unless the lesson explicitly says otherwise.

git tag -a v1.0.0 -m "First stable release"
git show v1.0.0
git tag --list

The tag points to the current commit unless you specify another revision. git show displays tag metadata and the tagged commit.

Practice: Tags and versions

Your task: Tag an older commit by hash as v0.9.0, then compare git show v0.9.0 with git show v1.0.0.

Common pitfall to avoid

A Git tag and a GitHub Release are related but not identical. GitHub Releases are higher-level published artifacts and notes built around Git tags.

Tags and versions: what to remember

Mark important commits with tags is complete when you can explain the state being changed before you run the command, not merely repeat the syntax.

Read further: official supporting documentation.

Reaching the recap and completing the quizzes are separate milestones.

Next lesson: Work with remotes, fetch, pull and push →

Mark important commits with tags