Skip to main content
DevOps Insightsguides & answers

Git · troubleshooting

Git tag already exists (rejected, would clobber existing tag)

A tag with that name already points at a different commit, and Git does not move tags unless you force it. Creating, pushing and fetching a moved tag all stop with a variant of this error.

Reproduced on Git 2.50.1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The tag name, and which commit it should point to.
  • For pushing a moved tag: permission to force-push tags, and agreement from whoever uses them.

Run this first

step 1 of 1
git ls-remote --tags origin

Look for A different commit for the tag than git rev-parse TAG shows locally

Shows where each tag points on the remote, without changing anything locally.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Which command failed?

Cause space

3 of 3 still possible

  • Creating a tag whose name is takenCommon
  • Pushing a tag that the remote has at another commitCommon
  • Fetching after someone else moved a tagCommon

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    git ls-remote --tags origin

    Shows where each tag points on the remote, without changing anything locally.

    Look for A different commit for the tag than git rev-parse TAG shows locally

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

Creating a tag whose name is taken

Common

A release script runs twice, or tags a version that was already tagged.

Confirm

git rev-parse --short TAG^{commit}
git log --oneline -1

Whether the existing tag already points at the commit you meant

Fix

  • If it already points at the right commit, nothing to do; make the script skip existing tags.
  • If it has not been pushed and points at the wrong commit, git tag -f TAG moves it.
  • If it has been pushed, use a new name such as v1.0.1, as the git-tag documentation advises.

Pushing a tag that the remote has at another commit

Common

The tag was moved locally with git tag -f, and the remote refuses to move its copy.

Confirm

git ls-remote --tags origin TAG
git rev-parse TAG

Two different commit IDs

Fix

  • Prefer a new tag name and push that.
  • If everyone agrees to move it: git push --force origin TAG, then tell everyone who fetched it to update.

Fetching after someone else moved a tag

Common

Your clone has the old tag. Plain pull keeps it without a word; fetch --tags, pull --tags and tools that fetch tags fail.

Confirm

git ls-remote --tags origin TAG
git rev-parse TAG

Different commit IDs for the same tag

Fix

  • Take the remote's version of every tag: git fetch --tags --force.
  • Or just that tag: git tag -d TAG, then git fetch origin tag TAG.
git fetch --tags --force

Reproduced on Git 2.50.1: printed t [tag update] and moved the tag.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Tags are meant to be permanent names for one commit, such as a release. When someone moves a tag to another commit, every copy of the repository that has the old one keeps it, and Git refuses to silently replace it. For a release that others may have used, the safe fix is a new tag name.

Words used on this page

Tag
A fixed name for one commit, usually a release such as v1.4.0.
Clobber
Overwrite: here, replace a local tag with the remote's different one.
What is actually happening

Reproduced on 23 October 2026 with Git 2.50.1 and with Git 2.43.0 on Ubuntu 24.04. git tag v1 for a name that existed printed fatal: tag 'v1' already exists, exit 128. Pushing a tag moved with git tag -f printed ! [rejected] v1 -> v1 (already exists) and Updates were rejected because the tag already exists in the remote, exit 1.

In another clone, after the tag was force-pushed, plain git pull exited 0 and quietly kept the old tag. git fetch --tags and git pull --tags failed with ! [rejected] v1 -> v1 (would clobber existing tag), exit 1. Since Git 2.20, fetch treats tag updates like pushes: they need --force.

So the error usually means someone moved a tag that was already shared, and your copy disagrees with the remote.

How to tell this is your problem
WhereWhat you see
git tagfatal: tag 'v1.0.0' already exists
git push! [rejected] v1.0.0 -> v1.0.0 (already exists) … Updates were rejected because the tag already exists in the remote.
git fetch --tags or git pull --tags! [rejected] v1.0.0 -> v1.0.0 (would clobber existing tag)

How to know it is actually fixed

  • git rev-parse TAG and git ls-remote --tags origin TAG print the same commit.

Stopping it happening again

  • Treat pushed release tags as permanent; fix a bad release with a new version.
  • Protect release tags on the Git host so they cannot be moved or deleted.
  • Make release scripts check for an existing tag before creating one.

Security considerations

  • A release tag that moves can make two people build different code under the same version. The git-tag documentation calls changing a published tag behind users' backs a serious security problem.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next