6 Git-Fehler, die Sie machen werden - und wie Sie sie beheben können

Ein wichtiger Grund, warum Entwickler ein Versionsverwaltungssystem wie Git verwenden, ist die Vermeidung von Katastrophen. Wenn Sie etwas so Einfaches tun, wie versehentlich eine Datei zu löschen, oder feststellen, dass die Änderungen, die Sie an einem Dutzend Dateien vorgenommen haben, alle schlecht beraten waren, können Sie das, was Sie getan haben, mit wenig Aufwand rückgängig machen.

Einige Git-Fehler sind einschüchternder und selbst für erfahrene Git-Benutzer schwer rückgängig zu machen. Aber mit ein wenig Sorgfalt - und vorausgesetzt, Sie geraten nicht in Panik - können Sie einige der schlimmsten Git-Katastrophen, die Programmierern bekannt sind, rückgängig machen.

Hier finden Sie eine Liste einiger der größeren Git-Boo-Boos sowie Tipps zum Zurücksetzen und Verhindern einiger von ihnen. Je weiter Sie die Liste durchgehen, desto größer werden die Katastrophen.

Git-Fehler Nr. 1: Sie haben vergessen, dem letzten Commit Änderungen hinzuzufügen

Dies ist einer der am einfachsten zu behebenden Git-Fehler. Angenommen, Sie haben einige Arbeiten in einer lokalen Niederlassung ausgeführt und dann festgestellt, dass Sie nicht die Anzahl der benötigten Dateien bereitgestellt haben. Oder Sie haben vergessen, bestimmte Details in die Festschreibungsnachricht aufzunehmen.

Keine Angst. Wenn Sie neue Änderungen vornehmen möchten, tun Sie dies zunächst. Geben Sie dann ein git commit --amend, um die Festschreibungsnachricht zu bearbeiten. Wenn Sie fertig sind, drücken Sie die Esc-Taste und geben Sie ein :xq, um den Editor zu speichern und zu verlassen. (Dieser letzte Schritt ist derjenige, der Git-Neulinge oft nervös macht, die nicht immer erkennen, dass der eingebaute Git-Editor ein eigenes Tier ist.)

Wenn Sie nur Dateien ändern und die Festschreibungsnachricht nicht ändern müssen, können git commit --amend --no-editSie die Dateien hinzufügen und den Nachrichtenbearbeitungsprozess überspringen.

Eine Möglichkeit, diese Art von Fehler zu vermeiden, besteht darin, die Art und Weise, wie Sie Commits in Git ausführen, zu optimieren. Wenn Sie an etwas arbeiten, bei dem Sie ständig kleine Verpflichtungen eingehen, um inkrementelle Revisionen zu verfolgen, führen Sie diese in einem Wegwerfzweig durch. Dokumentieren Sie dabei die wichtigsten Änderungen, die Sie irgendwo vornehmen. Warten Sie nicht, bis Sie mit der git commitBefehlszeile konfrontiert werden, um alles aufzuschreiben. Wenn Sie dann einen wichtigen Meilenstein erreicht haben, git merge --squashspeichern Sie die Ergebnisse in Ihrem Wegwerfzweig als einzelnes, sauberes Commit im Zweig "In Bearbeitung" und verwenden Sie die Notizen, die Sie für die Commit-Nachricht erstellt haben.

Git-Fehler Nr. 2: Sie haben Änderungen am (lokalen) Master vorgenommen

Ein weiterer häufiger Fehler: Sie haben pflichtbewusst eine Reihe von Änderungen vorgenommen ... aber versehentlich an den Hauptzweig Ihres Repos. Was Sie wirklich tun wollten, war, sie einem neuen Zweig zuzuweisen oder diesem devZweig, den Sie speziell für das Brechen von Änderungen haben.

Alles ist nicht verloren. Dieser Fehler kann in drei Befehlen behoben werden:

Git Branch New-Branch

git reset HEAD ~ --hard

Git Checkout New-Branch

Der erste Befehl erstellt den neuen Zweig, mit dem wir arbeiten möchten. Der zweite Befehl setzt den Hauptzweig auf kurz vor dem letzten Festschreiben zurück, behält jedoch die Änderungen bei, die Sie gerade im neuen Zweig vorgenommen haben. Schließlich wechseln wir in die neue Niederlassung, in der Ihre Änderungen auf Sie warten.

Wenn Sie mehrere Commits durchgeführt haben, verwenden Sie git reset HEAD~ --hard, wo ist die Anzahl der Commits, die Sie zurück möchten. Oder Sie können verwenden git reset , wo ist die Hash-ID des Ziel-Commits, wenn Sie das zur Hand haben.

Um diesen Fehler zu vermeiden, gewöhnen Sie sich an, neue Zweige zu erstellen und zu ihnen zu wechseln, auch wenn sie nur verworfen werden, wenn Sie eine Sitzung mit Ihrem Code beginnen.

Git-Fehler Nr. 3: Sie haben eine Datei oder ein Verzeichnis verworfen

Ein weiteres gemeinsames Katastrophe Wegwerfen fälschlicherweise den Inhalt einer Datei ... und nur über sie viele Commits zur Zweig herauszufinden , nach der Tatsache. Zum Glück gibt es eine einfache Lösung.

Verwenden git logSie zunächst das integrierte Git-Tool Ihrer IDE, um die Hash-ID für ein Commit zu ermitteln, bevor die Datei geändert wurde. Verwenden Sie als Nächstes, git checkout hash_id -- /path/to/fileum nur diese Datei aus dem betreffenden Commit auszuchecken. Beachten Sie, dass der Pfad relativ zum Stamm des Projekts sein sollte. Dadurch wird die frühere Version der Datei im Staging-Bereich Ihres Projekts platziert.

Wenn Sie einfach n Commits zurückgehen möchten, benötigen Sie die Hash-ID nicht. Sie können einfach den Befehl eingeben git checkout HEAD~ -- /path/to/file, wobei die Anzahl der Commits angegeben ist, die Sie zurückgeben möchten.

Wenn Sie ein ganzes Verzeichnis von Dateien auschecken möchten , verwenden Sie das Platzhalterformat von Git für Dateipfade. Wenn Sie beispielsweise eingeben  git checkout HEAD~1 -- ./src/**, erhalten Sie ein Commit zurück und stellen alles im /srcVerzeichnis aus dem Stammverzeichnis Ihres Projekts wieder her.

Git-Fehler Nr. 4: Sie haben versehentlich einen Zweig gelöscht

Hier ist ein Szenario, das wir alle fürchten: versehentlich einen ganzen Zweig aus unserem Repository löschen. Dieser kann je nach den Umständen entweder sehr leicht zu beheben oder etwas kniffliger sein.

Verwenden Sie zunächst git reflog, um das letzte für den Zweig vorgenommene Commit zu ermitteln. Verwenden Sie dann die Hash-ID, um einen neuen Zweig zu erstellen:

git checkout -b restored-branch

Beachten Sie, dass dadurch Ihr Speck nur dann entfroren wird, wenn der betreffende Zweig bereits zusammengeführt wurde. Wenn Sie einen nicht zusammengeführten Zweig zwangsweise gelöscht haben , haben Sie eine weitere Möglichkeit, ihn zu finden, vorausgesetzt, Sie haben ihn nicht git gcim Repository ausgeführt:

git fsck --full --no-reflogs --unreachable --lost-found

Dadurch wird eine Liste aller Commit-Hashes für Objekte ausgegeben, die nicht mehr erreichbar sind, einschließlich gelöschter Zweige. Suchen Sie am Ende der Liste nach einem Eintrag für "nicht erreichbares Festschreiben" und versuchen Sie, diese Hash-ID in einem neuen Zweig wiederherzustellen, um festzustellen, ob es sich um den von Ihnen verworfenen handelt. Wenn dies nicht der Fall ist, arbeiten Sie sich die Liste bis zur nächsten hoch und sehen Sie, was Sie wiederherstellen können.

Löschen Sie einen Zweig in der Regel nicht standardmäßig mit Gewalt, da Sie leicht einen nicht zusammengeführten Zweig verwüsten könnten, der noch etwas Wertvolles enthält. Wenn Sie gewohnheitsmäßig Zweige zwangsweise löschen, ist dies ein Zeichen dafür, dass Ihre Arbeitsgewohnheiten mit Zweigen weniger chaotisch sein müssen.

Git-Fehler Nr. 5: Sie haben den Remote-Zweig mit überlastet git push

Einmal habe ich an einer lokalen Kopie eines GitHub-Repositorys gearbeitet und versehentlich meinen Hauptzweig mit der --forceOption auf die Remote-Kopie verschoben . Am Ende hatte ich eine öffentliche Kopie eines Repos, das sich zu diesem Zeitpunkt nicht in einem brauchbaren Zustand befand. Big Ups.

Wenn Sie einen solchen Fehler gemacht haben und Ihr Repo kürzlich genug mit dem Remote-Repo synchronisiert wurde, können Sie ihn mit Ihrer eigenen Kopie des Remote-Repo-Zweigs beheben. Wechseln Sie zu dem Zweig, den Sie neu synchronisieren müssen, vorausgesetzt, Sie sind noch nicht dort, und geben Sie den folgenden Befehl ein:

git reset --hard /@{1}

Dadurch wird Ihre Kopie auf die letzte synchronisierte Version von zurückgesetzt . In meinem Fall war der Zweig masterund das Remote-Repo war origin, also hätte ich verwenden können git reset --hard origin/[email protected]{1}.

Verwenden Sie dann git push -f , um das Remote-Repository auf seinen früheren Status zurückzusetzen.

Eine Möglichkeit, dies zu verhindern, besteht darin, das Drücken von Gewalt zu verbieten. Sie können dies auf dem Remote-Git-Repo mit dem folgenden Befehl konfigurieren:

git config --system receive.denyNonFastForwards true

Es kann vorkommen, dass Sie einen Force-Push ausführen müssen, aber es ist wahrscheinlich am besten, diese Option zu aktivieren, wenn Sie sie benötigen, und auszuschalten, wenn Sie dies nicht tun.

Git-Fehler Nr. 6: Sie haben private Informationen an ein öffentliches Repo übergeben

Dies ist möglicherweise das schlimmste und schwierigste Git-Problem. Sie haben versehentlich vertrauliche Daten für ein öffentliches Repo festgeschrieben und möchten die Dateien chirurgisch aus dem Repo entfernen. Sie müssen sicherstellen, dass die vertraulichen Daten nicht gefunden werden können, selbst wenn Sie zu einem früheren Commit zurückkehren. Sie müssen dies jedoch tun,  ohne etwas anderes zu berühren.

Dies ist doppelt schwierig, wenn die betreffende Datei vor sechs Wochen festgeschrieben wurde und in der Zwischenzeit eine Lastwagenladung anderer wichtiger Arbeiten festgeschrieben wurde. Sie können nicht einfach einen Rollback durchführen, bevor die Datei hinzugefügt wurde. Sie werden alles andere in dem Prozess ruinieren.

Die gute Nachricht: Einige unerschrockene Git-Mavens haben ein Tool namens BFG Repo-Cleaner entwickelt, um fehlerhafte Daten aus Git-Repos zu entfernen. Mit BFG Repo-Cleaner können Sie schnell allgemeine Aufgaben an einem Repo ausführen, z. B. alle Dateien entfernen, die einem bestimmten Platzhalter entsprechen oder bestimmte Texte enthalten. Sie können sogar eine Datei übergeben, in der alle unerwünschten Texte aufgelistet sind.

BFG Repo-Cleaner ist im Wesentlichen eine Automatisierung für einen mehrstufigen Prozess git filter-branch. Wenn Sie die Dinge lieber von Hand erledigen möchten, bietet GitHub eine detaillierte Anleitung für den Vorgang. Das BFG-Tool deckt jedoch die überwiegende Mehrheit der gängigen Anwendungsfälle ab, von denen viele in die Befehlszeilenoptionen des Tools integriert sind. Außerdem ist der Vorgang lang und komplex und es ist allzu einfach, sich irgendwo auf dem Weg in den Fuß zu schießen, wenn Sie dies von Hand tun.

Beachten Sie, dass Sie beim Bereinigen von Daten aus einem lokalen Zweig, der an anderer Stelle synchronisiert werden muss, nur durch einen Force-Push auf die Remote-Zweige synchronisieren können. Der gesamte Commit-Baum muss neu geschrieben werden, sodass Sie im Wesentlichen einen völlig neuen Verlauf für Remote schreiben. Sie müssen auch sicherstellen, dass alle anderen nach Ihren Änderungen eine neue Kopie des umgeschriebenen Repos abrufen, da ihre Repos ebenfalls nicht mehr gültig sind.