Introduction

This SourceTree error usually means your local repository is trying to push a tag name that already exists on the remote but points to a different object. SourceTree is just surfacing a normal Git safety check: tags are generally expected to be immutable, so Git rejects the update instead of silently moving the remote tag.

Why Git Rejects The Push

A Git tag is a named reference to a specific commit or tag object. Release tags such as v1.2.0 are supposed to mean one exact snapshot. If the remote already has v1.2.0 and your local v1.2.0 points somewhere else, pushing it would rewrite history for everyone who uses that tag.

That is why Git accepts new tags but rejects conflicting ones.

The most common causes are:

• two developers created the same tag name independently
• you deleted and recreated a tag locally
• the remote tag changed and your local clone is stale
• SourceTree is pushing all tags, including one you did not mean to publish

Inspect The Conflict First

Before deleting anything, compare the local and remote tag targets.

git fetch --tags
git show v1.2.0
git ls-remote --tags origin v1.2.0

If you want only the commit id:

git rev-list -n 1 v1.2.0
git ls-remote --tags origin refs/tags/v1.2.0

If both sides point to the same commit, the problem may just be stale tag metadata in the GUI. A fresh fetch often resolves it. If they point to different commits, decide which tag should survive.

Fix Option 1: Keep The Remote Tag

If the remote tag is the correct one, remove or rename your local conflicting tag.

git tag -d v1.2.0
git fetch --tags

Or rename it locally before pushing:

git tag v1.2.0-local v1.2.0
git tag -d v1.2.0

This is the safest outcome when the tag has already been shared with a team or used by CI pipelines.

Fix Option 2: Replace The Remote Tag Intentionally

Sometimes the remote tag is wrong and your team has agreed to move it. In that case, delete the remote tag first, then push the corrected one.

git push origin :refs/tags/v1.2.0
git push origin v1.2.0

You can also delete the local tag and recreate it cleanly:

git tag -d v1.2.0
git tag -a v1.2.0 -m "Release v1.2.0" [commit-sha]
git push origin v1.2.0

Be careful here. Moving a published release tag can break deployments, changelog generation, or reproducible builds.

What SourceTree Is Doing Under The Hood

SourceTree does not change the underlying Git rules. When you click push with tags enabled, it runs a Git push that includes tag refs. If the remote already has a conflicting tag, Git rejects it and SourceTree shows the failure message.

So even if you prefer the GUI, it helps to understand the command-line equivalent:

git push origin --tags

That command pushes every local tag. If one tag conflicts, the push can fail even when the branch itself is fine.

A Better Workflow For Release Tags

The cleanest practice is to treat release tags as permanent. Once v1.2.0 is published, create v1.2.1 for the next release instead of moving the existing tag.

Good habits include:

• fetch tags before creating a new release tag
• use annotated tags for releases
• push the specific tag you intend to publish rather than --tags
• coordinate with the team before deleting or reassigning remote tags

Annotated tags are especially useful because they include a message and creator metadata:

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

Common Pitfalls

• Using git push --tags when you only meant to push one new release tag.
• Recreating a tag locally and assuming Git will overwrite the remote automatically.
• Deleting a remote tag without warning the team or checking CI dependencies.
• Forgetting to run git fetch --tags, which can leave SourceTree showing stale information.
• Confusing branch push problems with tag push problems. A branch can be pushable even while a tag is rejected.

Summary

• The error means the remote already has that tag name and Git refuses to overwrite it silently.
• Check whether the local and remote tags point to the same commit before fixing anything.
• If the remote tag is correct, delete or rename your local tag.
• If the remote tag must change, delete it explicitly and then push the replacement.
• Prefer pushing one tag at a time and treat published release tags as immutable.