Tutorial: Git-Code auf einen früheren Commit zurücksetzen

Was ist ein git reset?

Jedes Mal, wenn ein IT-Administrator eine Git-Bereitstellung übergibt, wird der 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 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 Head 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 des rückgängig machen – 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.

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.

Es gibt alternativ dazu eine schnellere Methode, um das 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 Heads zurück.

~ 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.

Beispiel für einen git revert

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

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

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.

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.

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 falschen 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.