Git Tags and Release Versions

A branch name moves as new commits arrive. A tag gives a commit a memorable version name, such as v1.2.0, so a team can identify the code it intended to release. Tags are not the same as GitHub Releases: a Release is a hosting-platform page that can add notes and downloadable assets around a tag.

A tag identifies a commit

A──B──C──D   main
      ↑
    v1.2.0

In this example main can move on to D, while v1.2.0 still identifies C. You normally treat published release tags as fixed. Git does allow tags to be moved or deleted, but doing so after other people depend on them makes the version name ambiguous and can break builds.

Lightweight and annotated tags

Kind	Create	What is stored	Typical use
Lightweight	git tag v1.2.0 <commit>	A name that directly points to an object	Temporary or local marker
Annotated	git tag -a v1.2.0 <commit> -m "Release v1.2.0"	A separate tag object with tagger, date, message, and target	Intentional release marker

An annotated tag can also be cryptographically signed when a project requires verified releases. For ordinary course exercises, an annotated tag with a useful message is enough.

Tag and publish a tested release

First, decide which exact commit passed review and tests. Do not automatically tag whatever your current HEAD happens to be. Inspect the graph and run the .NET tests:

git fetch origin
git log --oneline --decorate -8
dotnet test

If the tested commit is the current checkout, create an annotated tag there:

git tag -a v1.2.0 -m "Release v1.2.0"
git show v1.2.0
git push origin v1.2.0

To tag a different, verified commit, give its hash explicitly:

git tag -a v1.2.0 <tested-commit-hash> -m "Release v1.2.0"
git push origin v1.2.0

Use git tag --list to see local tags. git show v1.2.0 lets you inspect the annotated tag and the commit it names. The specific push above publishes only that tag. git push origin --tags publishes all local tags missing on the remote, which may expose draft or accidental labels. A normal branch push should not be assumed to publish tags; Git configuration and flags can affect that behavior.

After the tag exists on GitHub, you may create a GitHub Release based on it and add human-readable release notes or build artifacts. A Git tag alone does not build, deploy, or publish a .NET package. CI/CD must be configured separately to react to the tag if that is your release process.

Common mistakes

• Tagging an untested local commit instead of the exact reviewed release commit.
• Assuming git push origin main also published every tag.
• Using --tags without checking the full local tag list.
• Moving a public version tag instead of creating a new version after a correction.
• Confusing a branch, which advances, with a release tag, which should remain stable by convention.

Remember

Tags name specific commits. Annotated tags carry release metadata. Publish the chosen tag explicitly, then use your hosting and deployment workflow to create release notes and deliver the software.

Check your understanding

1. What stays the same when main gets a new commit: the branch tip or the existing version tag?
2. Why might git push origin --tags publish more than you intended?
3. Does creating a Git tag automatically deploy a .NET service?

Git tag reference · Git push reference