Einführung

git push lädt lokale Commits auf einen Remote hoch und aktualisiert dessen Branches und Tags. So wird Ihre Arbeit für Mitwirkende sichtbar.

Grundlegender Push

git push                          # aktueller Branch zu seinem Upstream
git push origin main              # explizit
git push -u origin feature/login  # Upstream setzen und pushen

Das Flag -u (oder --set-upstream) verknüpft den lokalen Branch mit dem Remote-Branch, sodass künftige git push und git pull keine Argumente benötigen.

Tags pushen

Tags werden standardmäßig nicht gepusht:

git push origin v1.2.3
git push origin --tags          # alle Tags
git push --follow-tags          # Tags, die von gepushten Commits aus erreichbar sind

--follow-tags ist die sicherste Voreinstellung für Release-Workflows.

Remote-Branches löschen

git push origin --delete feature/login
# äquivalent
git push origin :feature/login

Sicheres Force-Pushen

Das Umschreiben der Historie (Rebase, Amend, Squash) erfordert einen Force-Push. Bevorzugen Sie immer --force-with-lease, das sich weigert, Refs zu überschreiben, die sich auf dem Server bewegt haben:

git push --force-with-lease
git push --force-with-lease=feature/login:abcd1234

Verwenden Sie niemals blind --force auf einem geteilten Branch wie main.

Push-Defaults konfigurieren

git config --global push.default simple    # Standard seit 2.0
git config --global push.autoSetupRemote true   # 2.37+: automatisches -u

Mit gesetztem push.autoSetupRemote erstellt ein schlichtes git push auf einem neuen Branch automatisch den Remote-Branch und verknüpft beide.

Was beim Push passiert

1. Lokales Git verhandelt mit dem Remote, um gemeinsame Commits zu finden.
2. Es packt nur die fehlenden Objekte und lädt sie hoch.
3. Der Remote führt die Hooks pre-receive und update aus.
4. Wenn akzeptiert, werden Refs atomar aktualisiert.
5. Der Hook post-receive läuft (CI, Mirroring usw.).

Atomare und signierte Pushes

--atomic verwandelt Multi-Ref-Pushes in eine einzige Transaktion; entweder werden alle Refs aktualisiert oder keiner, was partielle Deployments verhindert. --signed sendet ein GPG-signiertes Push-Zertifikat, das einige Hosts zur Audit-Aufzeichnung loggen:

git push --atomic origin main release/1.2
git push --signed origin main

Für automatisierte Systeme erlaubt die Option --receive-pack, ein alternatives Receive-Pack auf dem Server zu spezifizieren, gelegentlich nötig für Hosts mit nicht-standardisierten Binaries. Verwenden Sie immer git push --dry-run, wenn Sie destruktive Pushes erstmals scripten.

Häufige Fehler

Auf main pushen, obwohl Sie einen Feature-Branch meinten, weil Sie vergessen haben, auf welchem Branch Sie sind. Führen Sie zuerst git status aus. git push --force gegen main verwenden und Commits anderer Personen umschreiben; erholen Sie sich über das Reflog des Remotes (falls Sie Shell-Zugriff haben) oder durch erneutes Pushen aus dem Klon eines Teamkollegen. Pushen ohne konfigurierte Credentials und an einer Passwortabfrage hängenbleiben; konfigurieren Sie einen Credential-Helper oder einen SSH-Schlüssel. Schließlich können große Pushes im letzten Moment fehlschlagen, wenn ein Hook sie ablehnt; in diesem Fall nennt die Ablehnungsnachricht den anstößigen Commit. Lesen Sie sie sorgfältig, anstatt blind erneut auszuführen.