How to fix “would clobber existing tag” in Git.

The safe answer

Do not start with git fetch --tags --force. First identify the tag named in the error, compare its local object with the remote reference and decide which target is authoritative. Preserve the local target under a backup ref before changing anything. If the remote tag is correct, delete or force-update only that verified local tag, then fetch it again. If the local tag is correct, stop and coordinate with whoever changed the remote; overwriting the remote tag affects everyone who consumes that release. Annotated tags can add a tag object around a commit, so inspect both the tag reference and its peeled commit before concluding that the content differs. A blanket force fetch may rewrite several local tags at once and hides the evidence you need to understand why they diverged. The commands below keep the diagnosis read-only until the backup exists and scope the eventual update to one tag.

1. Inspect the tag named in the error

# Replace v1.2.3 with the tag from the error.
git show-ref --tags --dereference | grep 'refs/tags/v1.2.3'
git ls-remote --tags origin 'refs/tags/v1.2.3*'

# Show what the local tag names.
git show --no-patch --decorate v1.2.3

The first command shows the local tag and, for an annotated tag, its peeled target. The second asks the remote without changing the repository. A line ending in ^{} is the peeled object behind an annotated tag.

2. Preserve the local target

# Keep a local recovery name before replacing the original tag.
git tag backup/v1.2.3 v1.2.3

# Confirm both names exist.
git show-ref --tags | grep 'v1.2.3'

This backup is local. If the tag marks a release that matters to a team, record the object IDs and resolve the disagreement with the maintainer before updating either side.

3. If the remote tag is authoritative, update that tag only

# Remove only the conflicting local name; the backup remains.
git tag -d v1.2.3

# Fetch only that tag from origin.
git fetch origin tag v1.2.3

# Verify the result.
git show --no-patch --decorate v1.2.3

An explicit forced refspec can also update one tag, but delete-and-fetch is easier to read and leaves the backup visible. Avoid deleting all local tags or forcing every tag when one name is the problem.

Why Git blocks the fetch

Tags normally identify stable release points. The official Git fetch documentation explains that tag updates which are not fast-forwards are rejected unless the update is forced. The Git tag documentation describes lightweight and annotated tags and recommends care when replacing a published tag. The error is a guard against silently changing what an existing version name means.