Git Tag Exists Locally but Not Remotely: Push One Exact Ref

A local tag is a separate reference. A branch push does not imply that every local tag is sent. Verify the intended tag and destination, then push the exact tag ref when that is the required release action.

Reproduce the boundary in a disposable fixture

Verify the destination and publish a selected tag without sending every local tag.

Use a new empty temporary directory for this fixture. The example creates only local test data. Commands marked with example.invalid do not identify a real service.

git init -q --bare remote.git
git init -q demo
cd demo
git config user.name Fixture
git config user.email fixture@example.invalid
printf 'release
' > app.txt
git add app.txt
git commit -qm initial
git tag -a v-fixture -m fixture
git remote add origin ../remote.git
git push -q origin HEAD:refs/heads/release
test -z "$(git ls-remote --tags origin refs/tags/v-fixture)"
git push -q origin refs/tags/v-fixture:refs/tags/v-fixture
git ls-remote --tags origin refs/tags/v-fixture

Observed result

849f415f52428021c1a7669b436b8d4633e727e2	refs/tags/v-fixture

What the result means

The remote in this example is another temporary local directory, not a hosted repository. The branch is present after the first push, while the selected tag is absent. The explicit second push creates the tag reference. Annotated tags also have a tag object; a peeled listing can show the commit it points to. Avoid comparing that commit line with the annotated tag object ID as if they must be identical.

Choose the correction for your workflow

For a real release, confirm git remote get-url --push --all origin, inspect git show TAG and decide exactly which tag should become public. An explicit refs/tags/NAME refspec avoids ambiguity with a branch of the same name. --tags sends all tags, which can include private experiments. --follow-tags has narrower annotated-tag reachability behavior and is not equivalent to sending every tag. Verify the exact remote ref with ls-remote after the authorized push.

Limits and the next check

A successful tag push can trigger external release automation, so do not treat it as a harmless diagnostic. The fixture contacts only a disposable local bare repository. If a remote tag already exists with a different target, stop and investigate ownership and release policy rather than forcing replacement. This procedure does not create a release page, build an artifact or prove that a deployment succeeded.

Related: Compare the related workflow boundary.

This isolated example was executed on macOS on November 10, 2026 (KST). Available tools: node v26.5.0, git git version 2.39.3 (Apple Git-145), npm 11.17.0, jq jq-1.7.1-apple. Shell fixtures use Bash and repository-path identity uses Python 3. This checks the illustrated contract, not your project, host service or every tool version.