How to fix ! [rejected] v1.0.0 -> v1.0.0 (already exists) in Git

First, understand what your local tag points to versus what exists on the remote:

# Show what your local tag points to
git show-ref --tags | grep v1.0.0

# Show what the remote tag points to
git ls-remote --tags origin | grep v1.0.0

# Compare the commits
git log --oneline -1 v1.0.0          # Local tag
git log --oneline -1 origin/v1.0.0   # May not work if not fetched

If the hashes differ, your local tag points to a different commit than the remote tag. You'll need to decide which version is correct before proceeding.

Fetch remote tags to see what exists:

git fetch --tags
git tag -l

The safest approach when you intentionally want to update a tag is to delete it from the remote first, then push your local version:

# Delete the tag on the remote
git push origin --delete v1.0.0

# Or using the colon syntax
git push origin :refs/tags/v1.0.0

# Now push your local tag
git push origin v1.0.0

This is the recommended approach because:
- It makes your intention explicit
- Other collaborators will see the tag was deleted and recreated
- It works even when force push is disabled on the remote

Note: If others have already fetched the old tag, they'll need to delete it locally and fetch again:

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

If you need to overwrite the remote tag in one command, use force push:

# Force push a specific tag
git push --force origin v1.0.0

# Or with the full ref path for clarity
git push --force origin refs/tags/v1.0.0:refs/tags/v1.0.0

# Alternative: use + prefix to force a specific ref
git push origin +refs/tags/v1.0.0

Warning: Force pushing is potentially destructive:
- The remote may have protections that prevent force pushing tags
- Other users may have already pulled the old tag
- Some CI/CD systems may have already used the old tag reference

To force push all tags (use with caution):

git push --force --tags origin

This overwrites ALL tags on the remote that differ from your local tags. Only use this if you're certain your local tags are authoritative.

The cleanest solution is often to use a new tag name instead of trying to move an existing tag:

# Delete the local tag you were trying to push
git tag -d v1.0.0

# Create a new tag with a different version
git tag -a v1.0.1 -m "Release v1.0.1"

# Push the new tag
git push origin v1.0.1

This approach is recommended when:
- The existing tag has already been used in production
- Other developers may have built software against the old tag
- You're following semantic versioning and should increment anyway
- The remote strictly enforces tag immutability

For pre-release or release candidate tags, consider using suffixes:

git tag -a v1.0.0-rc2 -m "Release candidate 2"
git push origin v1.0.0-rc2

If your local tags are out of sync with the remote and you want to accept the remote versions:

# Fetch all tags from remote, overwriting local conflicts
git fetch --tags --force

# Or using the long form
git pull --tags --force

This will update your local tags to match the remote, which resolves conflicts by accepting the remote's version.

To see which tags differ between local and remote:

# List local tags
git tag -l

# List remote tags
git ls-remote --tags origin

# Find tags that exist locally but not on remote
git tag -l | while read tag; do
  git ls-remote --tags origin | grep -q "refs/tags/$tag$" || echo "Local only: $tag"
done

Many Git GUI clients like SourceTree have a "Push all tags" option enabled by default, which can cause this error when you have old local tags that conflict with remote tags.

In SourceTree:

1. When pushing, uncheck "Push all tags to remotes" in the push dialog
2. Or go to Preferences > Git and disable "Push all tags to remotes"

To clean up old local tags that conflict:

# Delete all local tags
git tag -l | xargs git tag -d

# Fetch fresh tags from remote
git fetch --tags

Alternative: only delete specific conflicting tags:

# Find the specific tag causing the issue
git tag -d v1.0.0

# Fetch to get the remote version
git fetch --tags

After cleaning up, the push should succeed without tag conflicts.

Some Git hosting platforms (GitHub, GitLab, Bitbucket) allow protecting tags to prevent modification or deletion:

GitHub:
- Repository Settings > Branches & Tags > Tag protection rules
- Protected tags cannot be deleted or force-pushed

GitLab:
- Settings > Repository > Protected tags
- Only users with certain permissions can create matching tags

Bitbucket:
- Repository settings > Branch restrictions
- Can restrict tag creation and modification

If you're blocked by tag protection:

1. Ask a repository administrator to remove the protection temporarily
2. Have an admin delete the tag via the web interface
3. Use a different tag name that isn't protected
4. Request that an admin recreate the tag pointing to the correct commit

Checking tag protection (GitLab API example):

curl --header "PRIVATE-TOKEN: <your-token>" \
  "https://gitlab.com/api/v4/projects/<project-id>/protected_tags"

After resolving the issue, verify your tags are correct:

# Verify local and remote tags match
git show-ref --tags
git ls-remote --tags origin

# Check the tag points to the expected commit
git log --oneline -1 v1.0.0

Best practices to avoid this error in the future:

1. Push tags immediately after creation - don't let them sit locally

git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0  # Push right away

2. Use annotated tags for releases - they store metadata and are harder to accidentally move

git tag -a v1.0.0 -m "Release v1.0.0"  # Annotated (recommended)
git tag v1.0.0                          # Lightweight

3. Never reuse tag names - if a tag was published, consider it permanent

4. Coordinate with your team - ensure only one person/system creates release tags

5. Disable "Push all tags" in GUI clients unless you specifically need it