Introduction

Git tags are named references that usually mark releases, deploy points, or other important revisions. Creating a tag locally is only half the job. Other developers and CI systems cannot see it until you push it to a remote repository.

The exact command depends on whether you want to push one tag or every local tag. In both cases, the tag points to an existing commit, and Git sends that reference to the remote just like it sends branches.

Create the Tag First

If you have not created the tag yet, start there. Git supports lightweight tags and annotated tags.

A lightweight tag is just a name pointing at a commit:

git tag v1.2.0

An annotated tag stores metadata such as the tagger, date, and message:

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

For release markers, annotated tags are usually better because they carry more information and behave more like durable release artifacts.

You can inspect local tags with:

git tag
git show v1.2.0

Push a Single Tag

To push one specific tag to a remote named origin, use:

git push origin v1.2.0

This is the safest choice when you intentionally want to publish only one tag.

It does not push every tag you created locally. It pushes only the tag you named.

Push All Local Tags

If you want every local tag that is not yet on the remote, use:

git push origin --tags

This sends all tags to the remote. It is convenient, but it can also publish experimental or forgotten local tags you did not mean to share. Use it when that is truly what you want.

A more targeted alternative is to push exactly the tag you need.

Verify That the Tag Reached the Remote

You can verify locally by asking Git to list remote references:

git ls-remote --tags origin

You can also fetch tags from the remote and inspect them:

git fetch --tags
git tag

On hosting platforms such as GitHub, GitLab, or Bitbucket, tags are usually visible in the repository UI as well.

Delete or Replace a Remote Tag

Sometimes a tag was pushed by mistake. To delete a remote tag:

git push origin :refs/tags/v1.2.0

Or with the more explicit delete syntax:

git push --delete origin v1.2.0

If you recreate the tag locally after that and want to push the corrected version, delete the remote tag first, update the local tag, and then push again. Rewriting published tags is possible, but teams should do it carefully because other clones may already depend on the old tag reference.

Tags Versus Branches

A branch is expected to move as new commits are added. A tag is usually meant to stay fixed.

That difference is why tags are often used for:

• releases such as v1.0.0
• deployment snapshots
• rollback points
• published build references

If you are naming a moving line of work, use a branch. If you are naming a specific immutable moment, use a tag.

A Typical Release Workflow

A straightforward release sequence looks like this:

1git checkout main
2git pull
3git tag -a v1.2.0 -m "Release 1.2.0"
4git push origin main
5git push origin v1.2.0

That keeps the release marker explicit and avoids accidentally publishing unrelated local tags.

Common Pitfalls

A common mistake is assuming git push pushes tags automatically. By default, it usually does not. Branches and tags are separate references.

Another mistake is using git push --tags when you only intended to publish one release tag. That can expose internal or temporary tags.

People also forget that a local tag can point to the wrong commit. Always inspect the tag with git show before pushing it.

Finally, rewriting a tag after others have fetched it can create confusion. If a tag is already public, treat it like a published release artifact and change it only with clear coordination.

Summary

• Create the tag locally with git tag or git tag -a.
• Push one tag with git push origin <tag-name>.
• Push all local tags with git push origin --tags.
• Verify remote tags with git ls-remote --tags origin.
• Be careful when deleting or rewriting published tags because other clones may already rely on them.