Einführung

git push lädt Commits auf einen Remote hoch und aktualisiert dessen Refs. Anders als fetch ändert er den Zustand auf dem Server, weshalb Sicherheitsmechanismen existieren, um das Überschreiben der Arbeit anderer zu verhindern.

Die Sequenz

1. Remote-URL und Ziel-Refspec auflösen.
2. Verbindung öffnen.
3. Capabilities verhandeln.
4. Server kündigt aktuelle Werte der Refs an.
5. Client prüft jeden Push: Ist es ein Fast-Forward der Server-Ref?
6. Client packt fehlende Objekte und lädt sie hoch.
7. Server führt pre-receive-Hook aus.
8. Für jede Ref führt der Server den update-Hook aus und aktualisiert die Ref atomar.
9. Server führt post-receive-Hook aus.
10. Server meldet Erfolg oder Ablehnung an den Client.

Befehle

git push                                  # aktueller Branch zum Upstream
git push origin main                      # explizit
git push -u origin feature/login          # Upstream setzen
git push origin --delete feature/login    # Remote-Branch löschen
git push origin v1.0.0                    # einen Tag pushen
git push --follow-tags
git push --force-with-lease

Fast-Forward-Erzwingung

Standardmäßig wird ein Push abgelehnt, wenn er die Remote-Ref nicht per Fast-Forward voranbringen würde. Dies schützt davor, versehentlich Arbeit zu überschreiben, die andere gepusht haben:

 ! [rejected]   main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind ...

Beheben Sie es, indem Sie fetchen, integrieren und erneut pushen.

Force-Pushen

git push --force                   # gefährlich: ignoriert den Remote-Zustand
git push --force-with-lease        # sicherer: weigert sich, falls der Remote sich bewegt hat
git push --force-with-lease=feature/login:abc1234

--force-with-lease verlangt, dass die Remote-Ref noch dem entspricht, was Ihre Tracking-Ref sagt. Bevorzugen Sie es immer.

Atomare Pushes

git push --atomic origin branchA branchB

Mit --atomic gelingen entweder alle Updates oder keines; nützlich, wenn Refs sich gemeinsam bewegen müssen.

Push-Richtlinien

git config --global push.default simple        # aktueller Branch zu seinem Upstream
git config --global push.default current       # aktueller Branch zum Remote gleichen Namens
git config --global push.default upstream      # aktueller zum Namen des Upstreams
git config --global push.autoSetupRemote true  # 2.37+: automatisches -u für neue Branches

Server-seitige Hooks

Hosting-Plattformen führen pre-receive- und update-Hooks aus, um Richtlinien durchzusetzen (signierte Commits, Branch-Benennung, verpflichtend grünes CI). Wenn ein Push abgelehnt wird, nennt die Server-Nachricht die anstößige Ref oder den anstößigen Commit. Lesen Sie die Nachricht, bevor Sie es erneut versuchen.

Häufige Fehler

Force-Push auf einen geteilten Branch wie main und Commits anderer Personen umschreiben. Stimmen Sie sich ab oder verwenden Sie --force-with-lease nur auf privaten Branches. Tags einzeln pushen und vergessen, Commits zu pushen, was dangling Tags auf dem Server hinterlässt. Verwenden Sie --follow-tags. An den falschen Remote pushen, weil Sie mehrere konfiguriert haben; git push -v zeigt genau, wohin es geht. Schließlich: Erwarten, dass git push --delete Dateien löscht; es löscht Refs. Um Dateien zu löschen, committen Sie eine Entfernung und pushen Sie diesen Commit.