Git Push Force: So funktioniert es und wie du es sicher benutzt

Als Entwickler hast du das bestimmt schon mal erlebt: Du hast gerade gemerkt, dass dein Code im letzten Commit ein Problem hatte. Um diesen Fehler zu beheben, führst du ein paar Befehle aus und schreibst deinen lokalen Verlauf neu. Wenn du „ git push --force “ ausführst, um alles aufzuräumen, sagen dir deine Teamkollegen Bescheid, dass ein paar Commits fehlen oder deine Pipeline Builds nicht funktioniert.

In diesem Artikel zeige ich dir, was „ git push --force “ eigentlich macht, wann du es verwenden solltest und wie du Fehler vermeiden kannst. Wenn du gerade mit Git anfängst, empfehle ich dir, unseren Einführungskurs „ “ zu besuchen, um mehr über Versionskontrolle zu erfahren. Außerdem finde ich das Git-Spickzettel, das du runterladen kannst, echt hilfreich, weil es die gängigsten Git-Begriffe und -Befehle enthält.

Wann du vielleicht denkst, dass du „git push --force“ brauchst

Angenommen, du räumst deinen lokalen Commit-Verlauf auf, bevor du deine Arbeit pushst. Um deine Commit-Historie vor dem Mergen aufzuräumen, machst du Folgendes: git rebase -i main. Lokal sieht alles perfekt aus, also versuchst du, deinen Remote-Zweig mit „“ und einem einfachen „git push“ zu aktualisieren. Aber statt der üblichen Erfolgsmeldung zeigt Git dir einen Fehler an.

Es kann auch passieren, dass du versehentlich sensible Daten, wie zum Beispiel einen API-Schlüssel oder ein Passwort, festlegst und auf den Remote-Server überträgst. Nachdem du die lokale Historie umgeschrieben hast, um den problematischen Commit zu löschen, stellst du fest, dass ein normaler Push das Remote-Repository nicht aktualisiert und die sensiblen Daten erhalten bleiben. Stattdessen bekommst du eine Fehlermeldung.

! [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
hint: its remote counterpart. Integrate the remote changes (e.g.,
hint: 'git pull ...') before pushing again.

Dieser „Nicht-Vorlauf“-Fehler ist sozusagen die Sicherheitsvorkehrung von Git, die dir sagt, dass irgendwas in deinem Verlauf nicht mit dem auf dem Server übereinstimmt. Jetzt ist es echt verlockend, einfach „ git push --force “ zu machen, um diesen Fehler zu umgehen.

Das kann gut funktionieren, wenn du der Einzige bist, der an dem Branch arbeitet. Gemeinsame Projekte können aber schnell für Verwirrung sorgen oder die Arbeit von anderen löschen.

Was „git push --force“ wirklich macht

Normalerweise lässt Git dich deine Änderungen nur dann pushen, wenn dein lokaler Branch alles enthält, was bereits auf dem Remote-Server vorhanden ist, einschließlich deiner neuen Commits. Manchmal kann es aber sein, dass du deine Commit-Historie über „ git rebase “, „ “ oder „“ umschreiben oder sensible Daten löschen musst. Wenn du das machst, unterscheidet sich dein lokaler Branch vom Remote-Branch. Wenn du dann versuchst, einen neuen Commit zu pushen, zeigt Git den Fehler an, der den Remote-Branch vor dem Verlust von Arbeit schützt.

Mit „ git push --force “ sagst du Git, dass es die Sicherheitsüberprüfung überspringen und den Remote-Zweig mit dem Inhalt deines lokalen Zweigs überschreiben soll. 

So sieht das aus:

git push --force origin main

Damit wird der Hauptzweig des Remote-Repositorys an deinen lokalen Hauptzweig angepasst und alle Commits gelöscht, die nicht in deinem lokalen Zweig enthalten sind. 

Stell dir deinen Git-Zweig jetzt wie ein Kapitel in einem gemeinsamen Buch vor, das dein Team zusammen schreibt. Ein Standard-Push ist wie das Hinzufügen neuer Absätze am Ende eines Kapitels. Ein „ git push --force “ ist aber stärker und löscht das aktuelle Kapitel komplett und ersetzt es durch deine Version. 

Das Risiko bei der Verwendung von „ git push --force “ besteht darin, dass Mitarbeiter ihre Arbeit verlieren können, wenn sie ihre Änderungen auf den Commits basieren, die du gerade gelöscht hast. Im nächsten Abschnitt schauen wir uns an, was du bei der Arbeit mit dem Befehl „ --force “ beachten musst.

Warum das für dein Team alles kaputt machen kann

Wenn du deine Änderungen gewaltsam in einen freigegebenen Branch wie „ main “ oder „ develop “ schiebst, kann es zu folgenden Problemen kommen:

• Andere lokale Zweigstellen geraten aus dem Takt: Wenn deine Teamkollegen die alten Commits gezogen haben, die du jetzt aus dem Remote gelöscht hast, stimmen ihre lokalen Historie nicht mehr mit dem Server überein. Ihre Zweige verweisen auf Commits, die „verschwunden“ sind, was zu Verwirrung führt und 
• Das Ziehen führt zu verwirrenden Zusammenführungen oder Fehlern: Wenn jemand nach einem Force-Push von „“ versucht, „git pull“ auszuführen, weiß Git nicht, wie die umgeschriebene Historie mit der lokalen Abfolge der „ “-Commits abgeglichen werden soll. Das führt oft zu komischen Merge-Commits, kryptischen Fehlern oder Situationen, in denen Teammitglieder manuell eingreifen müssen, indem sie git fetch, git reset oder sogar re-clone des Branches ausführen.
• CI/CD-Pipelines können abstürzen: Pipelines brauchen oft einheitliche Commit-Hashes und eine lineare Historie. Ein Force-Push kann dazu führen, dass sie Tests nicht bestehen, falschen Code neu bereitstellen oder beim Neuaufbau auf veralteten Commits abstürzen.

Schau dir unseren Kurs „CI/CD für maschinelles Lernen ” an, um zu verstehen, wie man CI/CD-Workflows aufbaut. Ich empfehle dir auch unseren Kurs „Einführung in die Datenversionierung mit DVC“, um den Unterschied zwischen Datenversionierung und Codeversionierung zu verstehen.

Lass mich das mal erklären: Du bist im Zweig „ feature ” mit einem Teamkollegen. Lösche den Verlauf von „ “ und starte dann „ git push --force “. Ein paar Minuten später schickt dein Teamkollege seine Änderungen los. Sie sehen Fehler in Git. Wenn sie ziehen, gibt's Merge-Konflikte und eine durcheinandergebrachte Commit-Historie. In der Zwischenzeit stürzt deine CI-Pipeline wegen fehlender Commits ab. Jetzt verliert dein Teammitglied Zeit damit, den Ast zu entwirren, und der Einsatz verzögert sich.

Ein einziger Force-Push macht das alles möglich.

Die sicherere Option: git push --force-with-lease

Um solche Probleme zu vermeiden, empfehle ich die Verwendung von „ git push --force-with-lease “. Dieser Befehl fügt beim Pushen zu einem Remote-Branch eine Sicherheitsüberprüfung hinzu, um unerwartete Commits zu vermeiden.

git push --force-with-lease origin main

Stell dir „ --force-with-lease “ so vor, als würdest du fragen, ob die Luft rein ist, bevor du dich in etwas stürzt. Bevor irgendetwas passiert, wird sichergestellt, dass niemand anders den Branch geändert hat. Wenn alles so ist, wie du es zuletzt gesehen hast, wurde dein Verlauf aktualisiert. Wenn es aber neue Änderungen gibt, von denen du nichts wusstest, hält Git dich an und fordert dich auf, die Situation erst mal zu überprüfen. So schützt dieser Befehl die Leute, mit denen du zusammenarbeitest, immer vor versehentlichem Überschreiben.

Wie man einen fehlerhaften Force Push rückgängig macht

Wenn du ein paar Commits verlierst, mach dir keine Sorgen, du kannst sie immer noch wiederherstellen. Git speichert immer alle Änderungen am aktuellen Commit, auch das Umschreiben, und legt sie im reflog.

So kannst du verlorene Commits wiederherstellen:

Schritt 1: Verlorene Commits mit git reflog finden

Führ einfach „ git reflog “ aus, um den Verlauf deines Branches zu sehen.

git reflog

Deine Commits werden möglicherweise wie folgt angezeigt:

abc1234 HEAD@{1}: push: force push
def5678 HEAD@{2}: commit: add new feature

Schritt 2: Verlorenen Commit wiederherstellen

Wenn du den Commit-Hash gefunden hast, den du wiederherstellen willst, benutze den folgenden Befehl, um zum richtigen Branch zu gelangen.

git checkout def5678

Schritt 3: Erstell einen neuen Zweig

Um die Dateien sicher wiederherzustellen, leg einfach einen neuen Git-Zweig an.

git checkout -b recovery-branch

Schritt 4: Remote-Zweig wiederherstellen

Jetzt schick die wiederhergestellten Commits an den Branch:

git push origin recovery-branch

Denk dran, dass Reflog-Daten nur auf lokalen Rechnern gespeichert werden. Deshalb kannst du verlorene Commits nicht wiederherstellen, wenn keiner deiner Teamkollegen sie in der lokalen Umgebung gespeichert hat.

Ich empfehle dir unseren Git-Kurs für Fortgeschrittene, um mehr über die Zusammenarbeit und das Arbeiten mit Branches in Git zu erfahren.

Tipps für die sichere Verwendung von „git push --force“

Um das Risiko von Schäden zu verringern, solltest du diese guten Gewohnheiten beachten:

• Verwende lieber --force-with-lease als --force:  Diese Methode ist eine sicherere Option, die überprüft, ob sich der Remote-Zweig seit dem letzten Abruf geändert hat. Ich helfe dir dabei, deine Teamkollegen vor versehentlichem Überschreiben zu schützen.

• Vermeide es, Änderungen in geteilte Branches zu pushen: Mach niemals einen Force-Push zu geteilten Branches wie main, master, develop oder release. Mach Force Push nur auf deine Feature-Branches, wo du der einzige Mitwirkende bist, um Probleme zu vermeiden.

• Sag deinem Team Bescheid, bevor du den Push erzwingst: Wenn du einen Push auf einen geteilten Branch erzwingen musst, sag deinem Team Bescheid. So können sie ihre Arbeit speichern und Verluste vermeiden.

• Schützige Zweige verwenden: Du kannst den Schutz für deine Branches auch aktivieren, wenn du Plattformen wie GitHub, GitLab und Bitbucket nutzt. Das verhindert, dass du direkt was änderst und aus Versehen wichtige Zweige überschreibst.

Wenn du mehr über die Verwaltung privater Repos erfahren möchtest, schau dirunseren Kurs „Einführung in GitHub-Konzepte“ an, um zu verstehen, wie du Pull-Anfragen bei der Zusammenarbeit auf GitHub überprüfst.

Fazit

git push --force bietet eine coole Möglichkeit, die Historie deines Repos zu überarbeiten, egal ob du Commits bereinigen oder sensible Daten löschen willst. Sei immer vorsichtig, wenn du diesen Befehl benutzt, damit du den Arbeitsablauf deines Teams nicht durcheinander bringst.

Wenn möglich, benutze lieber --force-with-lease. Du hast mehr Kontrolle, ohne die Arbeit anderer zu gefährden. Mit ein bisschen Sorgfalt und Kommunikation kannst du deinen Git-Verlauf sauber halten, ohne deinem Team Probleme zu bereiten.

Ich empfehle dir, dir unsere Lernpfade „Git-Grundlagen“ und „GitHub-Grundlagen“ anzuschauen, um ein Experte in allen Bereichen von Git zu werden.