Übersicht

git push [<remote> [<refspec>...]] [--force-with-lease] [--tags] [--delete]

Beschreibung

Der git push-Befehl sendet lokale Commits an ein Remote-Repository und aktualisiert Remote-Branches, sodass sie mit Ihren lokalen übereinstimmen. Der erste Push eines neuen Branches erfordert üblicherweise -u, um Tracking einzurichten. Standardmäßig ist Push nicht-destruktiv: Er weigert sich, Remote-Historie zu überschreiben, die Sie nicht lokal haben. Verwenden Sie --force-with-lease, wenn Sie wirklich Remote-Historie umschreiben müssen (nach einem Rebase) — verwenden Sie niemals einfaches --force auf geteilten Branches.

Push gehorcht serverseitigen Regeln: Branch-Schutz, erforderliche Reviews, signierte Commits und Pre-Receive-Hooks können einen Push alle ablehnen. Lesen Sie die Fehlermeldung sorgfältig, wenn das passiert.

Im täglichen Einsatz integriert sich git push eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git push --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git push mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git push hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
-u, --set-upstream	Setzt Upstream für künftige Push/Pull-Defaults.
--force-with-lease	Force-Push nur, wenn die Remote-Ref Ihrem zuletzt gefetchten Wert entspricht.
--force / -f	Überschreibt Remote-Historie zwingend (gefährlich auf geteilten Branches).
--tags	Pusht alle lokalen Tags.
--delete	Löscht einen Remote-Branch.
--dry-run	Zeigt, was gepusht würde.
--all	Pusht alle Branches.
--atomic	All-or-Nothing-Update mehrerer Refs.

Beispiele

git push -u origin feature/login
    # Erster Push eines neuen Branches mit Tracking

    git push --force-with-lease
    # Sicherere Alternative zu --force nach einem Rebase

    git push origin --delete old-feature
    # Einen Remote-Branch löschen

    git push --tags
    # Alle lokalen Tags veröffentlichen

Häufige Fehler

Einfaches --force kann Commits von Kollegen auslöschen. Verwenden Sie stattdessen --force-with-lease. Direkt auf main zu pushen umgeht in vielen Teams das Code-Review — richten Sie Branch-Schutz ein. Das Vergessen von -u bedeutet, dass künftige git push-Befehle explizite Argumente brauchen.

Verwandte Befehle

git fetch, git pull, git remote, git tag