Hor - stock.adobe.com

So setzen Sie GitCode auf einen früheren Commit zurück

Für Entwickler sind git reset und git revert Lebensretter. Diese Beispiele zeigen, welcher Befehl am sinnvollsten ist, wenn während der Entwicklung Fehler auftreten.

Mit Git können IT-Teams eine Versionskontrolle einführen. Menschen machen Fehler und müssen deshalb manchmal zu früheren Versionen von Inhalten zurückkehren.

In Git gibt es Mechanismen, die es Programmierern ermöglichen, die Commits auf eine bekannte, gute Version zurückzusetzen. Es gibt jedoch potenzielle Auswirkungen auf den Code, wenn Teams diese Befehle ausführen.

Ein Commit ist die erfolgreiche Beendigung einer Aktion, die mit dem Befehl Commit abgeschlossen wird.

Was ist git reset?

Jedes Mal, wenn ein IT-Administrator eine Git-Bereitstellung festschreibt, wird dieser letzte Commit zum Kopf oder zur Spitze des Codebaums. Mit anderen Worten: zur aktuellen Version. Zum Zeitpunkt jeder Änderung erstellt der Git-Commit-Prozess einen Point-in-Time-Snapshot (PIT-Snapshot) der versionskontrollierten Dateien.

Je nach Zielsetzung kann ein Administrator das Code-Repository auf verschiedene Weise auf einen früheren Commit zurücksetzen – diesen Point-in-Time-Snapshot. Eine Möglichkeit ist der Befehl git reset.

Bevor Teams diesen Befehl verwenden, müssen sie verstehen, was git reset bewirkt. Je nach Verwendung des Befehls und den verwendeten Switches variieren die Ergebnisse. Verwenden Sie den Befehl mit Bedacht. Für git reset gibt es zwei Modi:

  • Git reset soft: Der Kopf (Head) des Codebaums wird in diesem Modus auf die angegebene frühere Commit-Instanz zurückgesetzt. Alle Dateien zwischen diesem PIT-Snapshot und jetzt werden auf staged gesetzt: Bereit zum Commit, aber noch nicht committed. Das ist der Standardmodus.
  • Git reset hard: Da die Änderungen nicht rückgängig gemacht werden können, sollten Sie diesen Modus mit äußerster Vorsicht verwenden. Dieser Befehl setzt alles zurück, verschiebt den Kopf zurück auf die angegebene Commit-Version und entfernt alle Änderungen, die dem Codebaum nach dieser bestimmten Versionsnummer hinzugefügt wurden. Der Befehl git reset bewirkt im Endeffekt eine harte Löschung aller Änderungen von jetzt – oder dem Zeitpunkt der Rückgängigmachung – bis zu dem angegebenen früheren Code-Commit. Er setzt den Codebaum auf die betreffende Version und löscht nicht übertragene Dateien.

Beispiel für einen git reset

Zunächst entscheiden Sie, wie weit Sie in der Versionsgeschichte zurückgehen wollen. Verwenden Sie den Befehl git log --oneline, um die vorherigen Commits anzuzeigen. Dieser Befehl liefert die Details der Commits.

Git-Log-Ausgabe
Abbildung 1: Der Code zeigt die Git-Log-Ausgabe früherer Übertragungen nach Ausführung des Befehls git log --oneline an.

Verwenden Sie die Commit-ID, um den Befehl auszuführen, sobald das Team eine Codeversion ausgewählt hat, zu der es seinen Baum zurücksetzen möchte. Im folgenden Beispiel wird ein Soft Reset verwendet, da --hard nicht angegeben ist. Der Code 3a96a8e steht für die Commit-ID, die aus der Git-Log-Ausgabe in Abbildung 1 hervorgeht.

Commit-ID 3a96a8e
Abbildung 2: Der Code zeigt die Commit-ID 3a96a8e an, mit der der Revert ausgeführt wird.

Es gibt alternativ dazu eine schnellere Methode, um die Commit zurückzusetzen, ohne die erforderliche Commit-ID zu kennen. Mit dem Code in Abbildung 3 setzen Admins die Codeversionen relativ zur aktuellen Position des Kopfes zurücksetzen.

~ 1 bezieht sich im Beispiel auf die Anzahl der Commits, zu denen der Codebaum zurückkehren wird. Die folgende Abbildung zeigt die Ergebnisse des Hinzufügens mehrerer Übertragungen und des anschließenden Zurücksetzens um eine Version.

Ausgabe
Abbildung 3: Der Code zeigt die Ausgabe nach der Ausführung von git reset head~1.

Beispiel für einen git revert

Admins können auch git revert anwenden. Dieser Befehl macht die Auswirkungen einer schlechten oder falschen Commits rückgängig, indem er einen Commit erzeugt, die das Gegenteil des fraglichen Commits bewirkt. Die Historie bleibt durch diese Rückgängigmachung intakt.

IT-Teams können erneut mit dem Befehl git log –oneline die aktuellen Commit-IDs einsehen.

Aktuelle Commit-IDs
Abbildung 4: Der Code zeigt die aktuellen Commit-IDs nach der Ausführung von git log --online an.

Mit einer ähnlichen Syntax wie beim reset-Befehl kehren sie zu einem bestimmten Commit zurück. Der Unterschied besteht jedoch darin, dass der Befehl die Commit-ID angibt, die rückgängig gemacht wird, und nicht die Commit-ID, auf die das Team zurücksetzt.

Git-Verlauf
Abbildung 5: Nachdem git revert 7b9a689 ausgeführt wurde, zeigt der Code den Git-Verlauf der vorherigen Übertragung an.

In Abbildung 5 gibt es einen zusätzlichen Parameter: --no-edit. Dieser verhindert, dass Git den Standard-Editor öffnet, um eine benutzerdefinierte Commit-Nachricht anzugeben.

Abbildung 6 zeigt, wie der Git-Verlauf aussehen wird.

Git-Verlauf
Abbildung 6: Der Code zeigt die Git-Historie an, nachdem er zur vorherigen Übergabe zurückgekehrt ist.

In diesem Szenario wurden alle Änderungen des zweiten Commits durch einen zusätzlichen Commit rückgängig gemacht, der das Gegenteil bewirkt.

git reset versus git revert

Es ist wichtig bei der Entscheidung zwischen git reset und git revert genau zu verstehen, was die beiden Methoden bewirken. Git reset löscht Commits aus dem Verlauf. Das ist wahrscheinlich die bessere Option, wenn Administratoren lokal arbeiten und keine Commits übertragen haben.

Wenn das Team jedoch die Commits veröffentlicht hat, sollten Sie stattdessen git revert verwenden. Auf diese Weise kann jeder, der den schlechten Commit gepusht hat, auch die revert Commits umsetzen.

Sie sollten diese Aktionen in einer lokalen Kopie des Repositorys testen, bevor Sie Änderungen vornehmen. Auf diese Weise können Administratoren bei Fehlern auf die Ausführung eines git pull zurückgreifen.

Erfahren Sie mehr über Softwareentwicklung

ComputerWeekly.de
Close