Egal, ob Sie isoliert Skripte schreiben oder mit einem Team zusammenarbeiten – es ist unerlässlich, die einzelnen Versionen des Codes nachverfolgen zu können. Möglicherweise wird irgendwann Code hinzugefügt, der am Ende nicht funktioniert. Die Möglichkeit, solche Änderungen rückgängig zu machen (ohne manuell Code zu löschen), kann das Projekt gegebenenfalls retten. In diesem Beitrag werde ich behandeln, wie man den Befehl Git reset nutzt, um zu einem früheren Commit des Codes in der Git-Quellcodeverwaltung zurückzugehen. Außerdem gehe ich auf die folgenden Themen ein:
Der Git-Client muss auf Ihrem System installiert sein. Sie können den Client hier herunterladen, und hier finden Sie eine Installationsanleitung. Der Git-Client ermöglicht das Ausführen von Git-Befehlen vom Terminal aus. Sie benötigen außerdem eine Datei, die geändert und für die Änderungen nachverfolgt werden sollen. In diesem Beitrag verwende ich ein PowerShell-Skript, aber Sie können eine beliebige Datei benutzen.
Git ist ein gängiges Tool zur Quellcodeverwaltung, das Änderungen mithilfe von sogenannten Commits nachverfolgt. Das Erstellen eines Commits ist wie das Speichern einer Version einer Datei bzw. einer Gruppe von Dateien. Mithilfe des Commits werden die einzelnen Dateiversionen nachverfolgt, indem eine eindeutige ID (bzw. SHA oder Hash) mit dem Commit verknüpft wird. Diese eindeutige ID ermöglicht es, Dateien im Repository auf vorherige Commit-Versionen zurückzusetzen.
Ein typischer Arbeitsablauf sähe wie folgt aus:
Wenn Sie jedoch kein zentrales Remote-Repository haben oder das Pushen/Pullen/Mergen von Code Sie nervös werden lässt, können Sie Git trotzdem nutzen, indem Sie es auf Ihrem lokalen System verwenden. Sie können Änderungen an Ihrem Code committen und diese Änderungen rückgängig machen, um sich mit Commits vertraut zu machen.
Der erste Befehl, mit dem Sie beginnen, ist Git init. Dieser Befehl initialisiert den aktuellen Ordner als Git-Repository. In diesem Beispiel initialisiere ich den Projektordner als Git-Repository.
Der Befehl fügt einen versteckten Ordner namens „.Git“ hinzu, in dem der aktuelle aktive Branch, Konfigurationsdateien, Aliasnamen und andere Daten aufgezeichnet werden.
Als nächstes brauche ich eine Datei, mit der ich arbeiten kann, um Änderungen nachzuverfolgen. Ich habe eine PowerShell-Skriptdatei namens „myScript.ps1“. Das Skript enthält eine for-Schleife, die fünfmal iteriert und etwas auf den Bildschirm ausgibt. Ich werde diese erste Schleife als meine äußere Schleife bezeichnen. Was der Code tut, ist nicht wichtig, es geht vielmehr um Codeänderungen für ein einfaches Skript.
Der nächste Schritt besteht darin, den Status des Repositorys anzuzeigen, indem Sie Git status ausführen. Der Status zeigt an, in welchem Branch ich mich befinde (vorerst befinde ich mich einfach im „Master“-Branch). Außerdem werden neue oder geänderte Dateien seit dem letzten Commit rot markiert angezeigt.
Wenn ich Dateien verfolgen möchte, um ihre Änderungen zu committen, muss ich sie mit dem Befehl Git add zum Staging-Bereich hinzufügen. Mit dem Befehl „Git add“ können eine oder mehrere Dateien angegeben werden, die zum Staging-Bereich hinzugefügt werden sollen. In meinem Fall habe ich nur eine Datei, also füge ich sie durch Angabe des Dateinamens hinzu. Anschließend überprüfe ich den Repository-Status, um das Skript im Staging-Bereich anzuzeigen.
Nun verfolge ich die Datei im Staging-Bereich und muss einen Commit für den Status des Repositorys erstellen. Ich verwende den Befehl Git commit mit dem Parameter -m , um dem Commit eine Nachricht zuzuweisen. Die Commit-Nachricht sollte kurz sein, aber gut beschreiben, welche Änderungen am Code vorgenommen wurden. Sobald ich den Commit abgeschlossen habe, führe ich einen erneuten Git status aus, um zu sehen, ob sich keine anderen Dateien im Staging-Bereich befinden oder seit dem letzten Commit geändert wurden.
Nun habe ich meine erste Commit-Nachricht in meinem Repository und muss eine Erweiterung zu meinem Code hinzufügen. Ich füge eine weitere for-Schleife innerhalb der äußeren Schleife hinzu, die ich als innere Schleife bezeichnen werde.
Wenn ich Git status erneut ausführe, sehe ich die gleichen Ergebnisse wie zuvor. Darin wird die Datei als nicht verfolgt angezeigt, da sich die Skriptdatei seit dem letzten Commit geändert hat. Ich werde den Arbeitsablauf der Befehle wiederholen, um die Datei hinzuzufügen und sie zu committen. Meine Commit-Nachricht gibt an, dass ich die innere Schleife hinzugefügt habe.
Da ich nun ein paar Commits im Repository habe, kann ich mich dem Befehl Git log zuwenden. Dieser Befehl zeigt die vorherigen Commits zusammen mit den Commit-Nachrichten an. Jeder Commit hat einen eindeutigen Hash-Wert, mit dem er identifiziert werden kann. In diesem Beispiel ist der letzte Commit derjenige, bei dem ich die innere Schleife hinzugefügt habe. Er wird durch den HEAD-Zeiger angegeben.
Nehmen wir nun an, ich möchte meine letzte Änderung nicht und möchte zu einer früheren Version des Skripts zurückkehren. Ich könnte die innere Schleife manuell löschen, da das Skript dafür klein genug ist. Für größere Code-Projekte wäre das hingegen problematisch. Ich könnte am Ende zu viel oder zu wenig Code entfernen, was dann wieder zu neuen Problemen führen würde.
Stattdessen kann ich die ersten sieben Zeichen des Hash-Werts des Commit-Protokolls verwenden, um das Repository auf eine frühere Version zurückzusetzen. Um diese Rückgängigmachung durchzuführen, verwende ich den Befehl Git reset und referenziere dabei den Hash des Commit-Protokolls:
Dieser Befehl setzt HEAD auf einen bestimmten Commit zurück. Auf dem Screenshot können Sie sehen, dass myScript.ps1 wieder im Staging-Bereich ist, mit den Änderungen seit dem Commit a6dd1c2. Wenn ich Git log erneut ausführe, ist HEAD nun wieder auf dem vorherigen Commit, und der Commit zum Hinzufügen der inneren Schleife wurde entfernt.
Um zurück zur Datei zu wechseln, muss ich die Datei aus dem Commit mit Git checkout auschecken. Sobald ich die Datei ausgecheckt habe, kann ich die Dateiinhalte anzeigen. Diese zeigen, dass nur die äußere Schleife vorhanden ist. Anschließend führe ich „Git status“ aus, um zu zeigen, dass der aktuelle Baum keine zu verfolgenden Änderungen hat.
Im Folgenden finden Sie jeweils eine Zusammenfassung und den Zweck der einzelnen PowerShell-Git-Befehle, die ich verwendet habe:
Wenn Sie neu in der Versionskontrolle sind und sich noch nicht zutrauen, mit Remote-Repositories zu arbeiten, können Sie trotzdem mit einem lokalen Repository arbeiten und die gleichen Funktionen nutzen. Mit diesen grundlegenden Git-Befehlen können Sie sich mit dem Git-Prozess zur Versionskontrolle vertraut machen.
