Muss ich nach einem Git-Tag noch pushen?

Kurz gesagt: Ja. Ein Tag, das Sie mit git tag erstellen, existiert nur in Ihrem lokalen Repository. git push überträgt es standardmäßig nicht mit — Tags müssen Sie separat pushen. Genau deshalb wundern sich viele, warum ihr frisch gesetztes v1.0.0 auf GitHub oder GitLab nicht auftaucht. Im Folgenden pushen Sie ein einzelnes Tag oder alle Tags gezielt, unterscheiden annotierte von leichtgewichtigen Tags und richten den Push so ein, dass er künftig automatisch mitläuft.

Warum bleiben Tags erst einmal lokal?

git push überträgt normalerweise nur Commits des aktuellen Branches. Tags sind eine eigene Referenzart unter refs/tags/ und werden dabei bewusst ausgeklammert. Der Grund: Ein Tag markiert einen bestimmten Commit als bedeutsam (etwa ein Release), und Git überlässt Ihnen die Entscheidung, wann dieser Zustand nach außen sichtbar werden soll.

Prüfen lässt sich das schnell. So sehen Sie Ihre lokalen Tags:

git tag

Und so, welche Tags das Remote bereits kennt:

git ls-remote --tags origin

Fehlt Ihr Tag in der zweiten Liste, obwohl es in der ersten steht, wurde es schlicht noch nicht gepusht.

Ein einzelnes Tag pushen

Der Standardfall — Sie haben ein Release-Tag gesetzt und wollen genau dieses übertragen:

git push origin v1.0.0

Ersetzen Sie v1.0.0 durch Ihren Tag-Namen. origin ist der übliche Name des Remotes; heißt Ihr Remote anders, setzen Sie dessen Namen ein. Danach ist das Tag auf dem Server sichtbar und löst dort ggf. eine CI/CD-Pipeline aus (dazu unten mehr).

Alle Tags auf einmal pushen

Wenn Sie mehrere Tags lokal angelegt haben und alle übertragen wollen:

git push origin --tags

Kurzform git push --tags funktioniert ebenfalls, sofern der aktuelle Branch ein Upstream-Remote hat. Achtung: --tags schiebt wirklich alle lokalen Tags hoch — auch alte, private oder versehentlich angelegte. In gemeinsamen Repositories ist das oft nicht erwünscht. Besser gezielt pro Tag pushen oder die weiter unten beschriebene --follow-tags-Variante nutzen.

Annotierte vs. leichtgewichtige Tags

Beim Pushen spielt der Tag-Typ eine Rolle. Git kennt zwei Arten:

Leichtgewichtiges Tag

Ein einfacher, benannter Zeiger auf einen Commit — ohne Metadaten:

git tag v1.0.0

Annotiertes Tag

Ein vollwertiges Objekt mit Autor, Datum und Nachricht (und optional signierbar). Für Releases die empfohlene Wahl:

git tag -a v1.0.0 -m "Release 1.0.0"

Der Unterschied wird beim automatischen Push relevant: git push --follow-tags überträgt nur annotierte Tags. Leichtgewichtige Tags bleiben dabei außen vor — ein weiterer Grund, für Releases annotierte Tags zu verwenden.

Tags automatisch mit pushen

Wenn Sie es leid sind, Tags separat zu pushen, gibt es zwei sinnvolle Ansätze.

Pro Push nur erreichbare annotierte Tags mitschicken:

git push --follow-tags

Das überträgt Ihre Commits und dazu die annotierten Tags, die auf mitgepushten Commits liegen — genau das, was man bei einem Release meist will, ohne Altlasten mitzuschleppen.

Dauerhaft aktivieren, sodass jeder git push sich so verhält:

git config --global push.followTags true

Danach reicht ein normales git push, um Commits samt zugehöriger annotierter Tags zu übertragen. Ohne --global gilt die Einstellung nur im aktuellen Repository.

Häufige Fehler und ihre Lösung

„Ich habe gepusht, aber das Tag ist nicht da.” Sie haben wahrscheinlich nur den Branch mit git push übertragen. Tags brauchen git push origin <tag> oder --tags.

„Das Tag zeigt auf den falschen Commit.” Ein bereits gepushtes Tag zu verschieben ist heikel, weil andere es evtl. schon gezogen haben. Lokal überschreiben Sie es mit git tag -f <tag> <commit>, remote erzwingen Sie den neuen Stand mit git push origin -f <tag>. Nutzen Sie das nur, wenn Sie sicher sind, dass noch niemand das alte Tag verwendet — mehr zu den Risiken erzwungener Übertragungen lesen Sie unter /git-force-push-was-es-ist-und-wie-man-es-verwendet/.

„Ich muss ein Remote-Tag wieder entfernen.” Ein Tag auf dem Server löschen Sie so:

git push origin --delete v1.0.0

Ältere Git-Versionen nutzen die gleichwertige Syntax git push origin :refs/tags/v1.0.0. Das lokale Tag bleibt dabei bestehen; entfernen Sie es zusätzlich mit git tag -d v1.0.0.

„Ich sehe die Tags anderer nicht.” Beim git fetch/git pull kommen nicht immer alle Tags mit. Holen Sie sie explizit:

git fetch --tags

Tags und CI/CD

In vielen Projekten löst ein gepushtes Tag automatisch einen Build oder ein Release aus. GitHub Actions reagiert etwa auf push-Events mit einem tags-Filter, GitLab CI über rules mit $CI_COMMIT_TAG. Solange das Tag nur lokal liegt, passiert nichts — die Pipeline startet erst mit dem Push. Wenn Ihr Release-Workflow also „nicht anspringt”, ist das nicht gepushte Tag eine der häufigsten Ursachen.

Mehr zu verwandten Git-Themen finden Sie unter /wie-loesche-ich-einen-git-branch-lokal-und-remote/ und /ist-git-fetch-und-merge-dasselbe-wie-pull/.

FAQ

Pusht git push Tags automatisch mit? Nein. Standardmäßig überträgt git push nur Commits des Branches. Tags gehen nur mit git push origin <tag>, git push --tags oder — für annotierte Tags — mit git push --follow-tags. Dauerhaft aktivieren Sie Letzteres per git config push.followTags true.

Was ist der Unterschied zwischen --tags und --follow-tags? --tags pusht ausnahmslos alle lokalen Tags, auch leichtgewichtige und alte. --follow-tags überträgt nur annotierte Tags, die auf gerade mitgepushten Commits liegen — deutlich sauberer für Release-Abläufe.

Wie lösche ich ein falsch gesetztes Tag wieder? Lokal mit git tag -d <tag>, auf dem Remote mit git push origin --delete <tag>. Beides ist nötig, wenn das Tag bereits gepusht wurde — sonst existiert es an einer der beiden Stellen weiter.