git push wird mit '! [rejected] non-fast-forward' abgelehnt? Die Remote hat Commits, die dir fehlen. So holst du sie sauber nach und pushst gefahrlos.
Aufwand:
ca. 10 Min.
Das Symptom
Du bist mit deiner Arbeit fertig, tippst git push – und statt eines grünen
Erfolgs kommt ! [rejected] mit dem Zusatz „failed to push some refs“ und
„Updates were rejected because the remote contains work that you do not have
locally“. Dein Commit bleibt hartnäckig auf deinem Rechner.
Die „Layer 8“-Wahrheit
git schützt hier fremde Arbeit vor dir – und deine vor dir selbst. Der Branch auf
der Remote hat sich weiterbewegt: Ein Kollege hat gepusht, oder du selbst von
einem zweiten Gerät. Würde git deinen Push jetzt durchwinken, verschwänden diese
Commits spurlos. Also verweigert es und nennt den Grund non-fast-forward – dein
Stand ist keine bruchlose Fortsetzung der Remote. Der gefährliche Reflex ist
git push --force: Er macht genau das, wovor git dich bewahren wollte, und
kann Stunden fremder Arbeit auslöschen. Der ruhige Weg ist immer derselbe – erst
holen, dann einreihen, dann pushen.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Ursache verstehen
Der Push scheitert nicht an dir, sondern an neuen Commits auf der Remote. Dein lokaler Branch und der Remote-Branch sind auseinandergelaufen – bevor du hochlädst, musst du beide zusammenführen.
2.
Remote-Commits holen und einreihen
Die fremden Commits herunterladen und deine eigenen sauber dahinter setzen. --rebase hält die History linear, statt einen Merge-Commit zu erzeugen:
git pull --rebase origin main
3.
Etwaige Konflikte auflösen
Kollidieren Änderungen, stoppt der Rebase. Die betroffenen Dateien bereinigen, die Auflösung anmelden und fortsetzen – oder im Zweifel abbrechen:
git add <datei>
git rebase --continue
# oder zurück: git rebase --abort
4.
Jetzt pushen
Nachdem dein Stand die Remote lückenlos fortsetzt, ist der Push ein einfacher Fast-Forward:
git push origin main
5.
Nur bei bewusster History-Änderung erzwingen
Hast du absichtlich eigene Commits umgeschrieben (z. B. per interaktivem Rebase auf einem eigenen Branch), nutze die sichere Variante. Sie bricht ab, falls doch jemand anderes zwischenzeitlich gepusht hat:
git push --force-with-lease origin main
Häufige Fragen (FAQ)
?Was bedeutet non-fast-forward?
Auf der Remote liegen Commits, die du lokal nicht hast – jemand (oder du selbst von einem anderen Rechner) hat inzwischen gepusht. Dein Push würde diese Commits überschreiben, also blockiert git ihn. 'fast-forward' geht nur, wenn dein Stand die Remote lückenlos fortsetzt.
?Warum nicht einfach --force benutzen?
Weil --force die fremden Commits auf der Remote gnadenlos überschreibt – bei geteilten Branches ein sicherer Weg, die Arbeit anderer zu vernichten. Der richtige Weg ist, die Remote-Commits erst zu holen und einzureihen. Nur wenn du bewusst deine eigene History umschreibst, ist --force-with-lease vertretbar.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
git stoppt mit 'Your local changes would be overwritten by merge/checkout'? So rettest du deine Änderungen per commit oder stash, statt sie zu verlieren.