How to Create and Push Git Tags

A Git tag gives a commit a memorable name, often to mark a release such as v1.2.0. Tags are useful for release notes, deployment workflows, and checking out a known version, but unlike branches they do not normally move forward as new work is committed. Learn how to create a tag, publish it to a remote, and verify the result.

Check the commit before tagging it

Before you tag a release, confirm that you are on the intended branch and that the commit is the one your project has approved for release:

git status
git log -1 --oneline

Agree on a tag naming convention with your team. Many projects use version numbers such as v1.2.0, but Git itself does not enforce semantic versioning or any particular name format.

Create an annotated tag for a release

An annotated tag stores a message, tagger name, and date in addition to the reference to a commit. It is generally the better choice for releases and other durable milestones:

git tag -a v1.2.0 -m "Release v1.2.0"

This creates the tag at the commit currently checked out. To tag a different commit, specify its identifier after the tag name, for example git tag -a v1.2.0 abc1234 -m "Release v1.2.0". Use a commit from your repository rather than the illustrative abc1234 value.

Annotated tags vs lightweight tags

A lightweight tag is only a name that points directly to a commit. Create one with git tag v1.2.0. It can be convenient for a temporary local marker, but it does not include tag metadata or a release message. For releases that should be documented and shared, use an annotated tag with git tag -a.

Either type can be pushed. Some Git workflows and hosting features distinguish annotated tags, so check the expectations of your release process.

Push a Git tag to a remote

Creating a tag locally does not automatically publish it. Push one named tag to the remote, commonly origin, with:

git push origin v1.2.0

To push every local tag to that remote, use:

git push origin --tags

This publishes all local tags, which may include older or unintended tags. When you want to publish annotated tags reachable from the commits being pushed, git push --follow-tags is a more selective option. For a release, explicitly pushing its tag is often the clearest choice.

List and verify tags

List local tags, optionally matching a pattern, and inspect the release tag and commit it points to:

git tag --list
git tag --list "v1.*"
git show v1.2.0

To list tags available on a remote without fetching their objects, use git ls-remote --tags origin. After fetching, git tag --list shows local tags. If a teammate pushed a tag after your last fetch, retrieve tags with git fetch --tags.

Correct a tag carefully

Avoid moving or reusing a tag that has already been published as a release: other people and automation may already rely on the commit it identifies. If a published release tag is wrong, follow your team's release policy, communicate the correction, and consider creating a new version instead.

For an unpublished local tag that you are sure you want to replace, delete it and recreate it:

git tag -d v1.2.0
git tag -a v1.2.0 -m "Release v1.2.0"

Deleting a local tag does not delete the remote tag. Removing a published remote tag affects other users and release systems, so coordinate first and use your hosting provider's documented procedure.

Git tag FAQ

Does git push send tags automatically?

A normal git push does not necessarily publish every local tag. Push the release tag by name, use --tags for all local tags, or use --follow-tags for reachable annotated tags.

What is the difference between a Git tag and a branch?

A branch normally advances as you commit new work. A tag names a specific commit and is typically kept fixed, especially after it has been shared as a release marker.

Can I tag an older commit?

Yes. Provide the commit identifier when creating the tag, such as git tag -a v1.2.0 COMMIT_ID -m "Release v1.2.0", then verify the result with git show v1.2.0.