Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Force Push in GitHub aktivieren: Befehl & Sicherheit

    · Weswegen-Redaktion
    Programmierung

    Ein Force Push überschreibt die Historie eines Remote-Branches mit dem Stand, den Sie lokal haben. Anders als der normale git push verlangt Git dabei nicht, dass Ihr Branch ein sauberer Nachfolger des Remote-Standes ist. Genau deshalb ist die Frage „Wie aktiviert man das?“ doppeldeutig: Auf einem gewöhnlichen Branch, für den Sie Schreibrechte haben, ist Force Push bereits verfügbar. Blockiert wird er nur, wenn auf GitHub eine Branch-Protection-Regel greift. Sie brauchen also beides: den richtigen Befehl – inklusive der sicheren Variante – und, für geschützte Branches, die passende GitHub-Einstellung.

    Was ein Force Push tatsächlich tut

    Normalerweise akzeptiert der Remote einen Push nur, wenn Ihr lokaler Branch alle Commits des Remote-Branches enthält und obendrauf neue hinzufügt (ein sogenannter Fast-Forward, siehe Was ist ein Git Fast-Forward?). Weicht Ihre Historie ab – etwa weil Sie Commits umgeschrieben haben – lehnt Git den Push ab.

    Mit --force heben Sie diese Schutzprüfung auf. Der Remote-Branch zeigt danach exakt auf Ihren lokalen Commit. Alles, was auf dem Remote lag und nicht Teil Ihrer lokalen Historie ist, verschwindet aus dem Branch-Verlauf. Deshalb ist Force Push kein Werkzeug für den Alltag, sondern für gezielte Korrekturen an einer Historie, die Sie bewusst verändert haben.

    Wann ein Force Push nötig ist

    Es gibt einige klar umrissene Fälle, in denen es keinen anderen Weg gibt:

    • Nach einem interaktiven Rebase (git rebase -i HEAD~3), bei dem Sie Commits neu ordnen, zusammenfassen oder umformulieren. Die Commit-Hashes ändern sich, der Remote kennt die alten – nur ein Force Push bringt beide zusammen.
    • Nach git commit --amend, wenn Sie den letzten, bereits gepushten Commit nachträglich ändern (Tippfehler in der Nachricht, vergessene Datei).
    • Nach git reset --hard <commit>, um versehentlich gepushte Commits vom Branch zu entfernen.
    • Beim Entfernen sensibler Daten (Passwörter, Keys) aus der Historie, meist in Kombination mit git filter-repo.

    In all diesen Fällen betrifft der Force Push idealerweise nur Ihren eigenen Feature-Branch, an dem sonst niemand arbeitet.

    Der Befehl – und die sichere Variante

    Der bekannte Befehl lautet:

    git push --force

    Kurzschreibweise über das Refspec-Präfix +:

    git push origin +feature-branch

    Beide überschreiben den Remote-Branch bedingungslos. Das ist auch das Problem: Hat in der Zwischenzeit ein Kollege etwas auf denselben Branch gepusht, löschen Sie dessen Commits, ohne es zu merken.

    --force-with-lease statt --force

    Verwenden Sie im Team praktisch immer die abgesicherte Variante:

    git push --force-with-lease

    --force-with-lease überschreibt nur dann, wenn der Remote-Branch noch genau auf dem Commit steht, den Ihr lokales Git als letzten Remote-Stand kennt – gemeint ist die Remote-Tracking-Referenz origin/<branch>. Hat ein Kollege zwischenzeitlich gepusht und Sie haben diesen Stand noch nicht abgeholt, bricht der Befehl mit einer stale info-Meldung ab, statt fremde Arbeit zu vernichten.

    Wichtig und oft falsch verstanden: Führen Sie unmittelbar davor kein git fetch oder git pull aus. Beide aktualisieren origin/<branch> auf den neuen Remote-Stand – die Lease-Prüfung hält den fremden Push dann für „bereits gesehen“ und überschreibt ihn trotzdem. Der Schutz wirkt also genau dann, wenn Ihre Remote-Tracking-Referenz noch den alten Stand zeigt. Wollen Sie den erwarteten Commit unabhängig davon festnageln, geben Sie ihn explizit an: git push --force-with-lease=<branch>:<sha>.

    Force Push auf geschützten Branches erlauben

    Kommt Ihr Force Push nicht durch und die Fehlermeldung nennt einen protected branch (typisch: GH006: Protected branch update failed oder remote: error: ... protected branch hook declined), liegt es nicht am Befehl, sondern an einer Regel im Repository. Geschützte Branches wie main blockieren Force Pushes standardmäßig. Das Erlauben passiert in den Repository-Einstellungen und setzt Admin-Rechte voraus.

    Über die klassische Branch Protection:

    1. Öffnen Sie das Repository auf GitHub und gehen Sie zu Settings › Branches.
    2. Bearbeiten Sie die Regel, die auf Ihren Branch passt (oder legen Sie über Add branch protection rule eine an).
    3. Aktivieren Sie das Kästchen Allow force pushes.
    4. Optional lässt sich einschränken, wer force-pushen darf („Specify who can force push“).
    5. Speichern mit Save changes.

    Nutzt Ihr Repository die neueren Rulesets (Settings › Rules › Rulesets), suchen Sie dort die aktive Regel und deaktivieren Sie die Option Block force pushes. In beiden Fällen wird die Änderung sofort wirksam – ein erneuter git push --force-with-lease sollte nun durchlaufen.

    Ein Hinweis zur Vorsicht: Force Push auf main oder einem gemeinsam genutzten Release-Branch schreibt die Historie für alle um. Wer den Branch bereits ausgecheckt hat, muss anschließend selbst nacharbeiten (siehe FAQ). Aktivieren Sie die Option nur bewusst und schalten Sie sie im Zweifel danach wieder ab.

    Typische Fehler und ihre Lösung

    „Updates were rejected because the tip of your current branch is behind“ Das ist der Normalfall vor einem Force Push: Ihre Historie weicht ab. Prüfen Sie mit git log --oneline origin/branch..branch, ob die Abweichung gewollt ist, und pushen Sie dann mit --force-with-lease.

    --force-with-lease bricht mit „stale info“ ab Auf dem Remote liegen Commits, die Sie lokal nicht kennen. Nicht blind --force hinterherschieben. Holen Sie erst mit git fetch den aktuellen Stand, sehen Sie sich die fremden Commits an und entscheiden Sie, ob Sie sie einarbeiten oder verwerfen.

    GH006: Protected branch update failed Branch-Schutz blockiert. Entweder erlauben Sie Force Pushes wie oben beschrieben, oder – der bessere Weg auf main – Sie arbeiten über einen Feature-Branch und einen Pull Request statt direkt auf dem geschützten Branch.

    Falscher Branch überschrieben Ist Ihnen das passiert, ist meist noch nichts verloren: Auf dem betroffenen Rechner findet git reflog den überschriebenen Commit-Hash, mit git reset --hard <hash> und einem erneuten (kontrollierten) Push stellen Sie den Stand wieder her.

    Wann Sie besser nicht force-pushen

    Auf Branches, an denen mehrere Menschen arbeiten oder von denen andere abzweigen, richtet ein Force Push mehr Schaden als Nutzen an. Statt die Historie umzuschreiben, ist ein zusätzlicher Commit – etwa ein git revert, der eine Änderung sauber rückgängig macht – fast immer die richtige Wahl. Force Push gehört auf Ihre eigenen, noch nicht gemergten Feature-Branches. Wer diese Grenze einhält, hält das Risiko klein und den Rest des Teams handlungsfähig.

    Verwandt: Git-Force-Push – was es ist und wie man es verwendet und Einen Git-Branch lokal und remote löschen.

    FAQ

    Muss ich Force Push in GitHub erst irgendwo einschalten? Nein – auf einem normalen Branch mit Schreibrechten funktioniert git push --force sofort. Eine Einstellung brauchen Sie nur, um die Sperre auf einem geschützten Branch aufzuheben (Settings › Branches bzw. Rulesets).

    Was ist der Unterschied zwischen --force und --force-with-lease? --force überschreibt bedingungslos. --force-with-lease überschreibt nur, wenn der Remote seit Ihrem letzten git fetch unverändert ist, und schützt so vor dem versehentlichen Löschen fremder Commits. Im Team ist die Lease-Variante der Standard.

    Kann ein Force Push meine Commits endgültig löschen? Aus dem Branch-Verlauf verschwinden sie sofort. Solange ein beteiligter Rechner die Commits noch kennt, sind sie über git reflog für eine Weile auffindbar und wiederherstellbar. Verlassen sollten Sie sich darauf nicht – prüfen Sie vor jedem Force Push, was Sie überschreiben.