Git
Chapters ▾ 2nd Edition

2.4 Git Grundlagen - Ungewollte Änderungen rückgängig machen

Ungewollte Änderungen rückgängig machen

Es kommt sicherlich irgendwann der Zeitpunkt, an dem Sie eine Änderung rückgängig (engl. undo) machen wollen. Wir werden hier einige grundlegende Werkzeuge besprechen, mit denen sie genau das tun können. Seien Sie vorsichtig, man kann diese Aktionen nicht immer rückgängig machen. Das ist einer der wenigen Bereiche in Git, in denen Sie ihre Arbeit verlieren könnten, wenn Sie etwas falsch machen.

Eines der häufigsten Undos tritt auf, wenn Sie zu früh committen und möglicherweise vergessen haben, einige Dateien hinzuzufügen, oder wenn Sie Fehler in ihrer Commit-Nachricht haben. Wenn Sie den Commit erneut ausführen möchten, führen zusätzlichen Änderungen vor, die Sie vergessen haben, stellen diese bereit (engl. stage) und committen erneut mit der Option --amend:

$ git commit --amend

Dieser Befehl übernimmt Ihre Staging-Area und verwendet sie für den Commit. Wenn Sie seit Ihrem letzten Commit keine Änderungen vorgenommen haben (z.B. Sie führen diesen Befehl unmittelbar nach Ihrem vorherigen Commit aus), dann sieht Ihr Snapshot genau gleich aus; Sie ändern nur Ihre Commit-Nachricht.

Der gleiche Commit-Message-Editor wird aufgerufen, enthält aber bereits die Nachricht Ihres vorherigen Commits. Sie können die Nachricht wie gewohnt bearbeiten, aber sie überschreibt den vorherigen Commit.

Wenn Sie zum Beispiel die Änderungen in einer Datei, die Sie zu dieser Übertragung hinzufügen wollten, vergessen haben, können Sie etwas Ähnliches durchführen:

$ git commit -m 'Initial commit'
$ git add forgotten_file
$ git commit --amend

Sie erhalten am Ende einen einzigen Commit – der zweite Commit ersetzt die Ergebnisse des ersten.

Anmerkung

Es ist wichtig zu verstehen, dass, wenn Sie Ihren letzten Commit ändern, Sie ihn weniger reparieren, als ihn komplett durch einen neuen, verbesserten Commit ersetzen. Der alte Commit wird aus dem Weg geräumt und der neue Commit an seine Stelle gesetzt. Tatsächlich ist es so, als ob der letzte Commit nie stattgefunden hätte und er nicht mehr in Ihrem Repository-Verlauf auftaucht.

Der naheliegendste Nutzen für die Änderung von Commits besteht darin, kleine Verbesserungen an Ihrem letzten Commit vorzunehmen, ohne Ihren Repository-Verlauf mit Commit-Nachrichten der Form „Ups, vergessen, eine Datei hinzuzufügen“ oder „Verdammt, einen Tippfehler im letzten Commit behoben“ zu überladen.
Anmerkung

Ändern Sie nur lokale Commits, die noch nicht gepusht wurden. Das Ändern zuvor übertragener Commits und das forcierte pushen des Branches verursacht Probleme bei ihren Mitstreitern. Weitere Informationen darüber, was dabei passiert und wie Sie es wieder gerade ziehen können, wenn Sie sich auf der Empfängerseite befinden, finden Sie unter Die Gefahren des Rebasing.

Eine Datei aus der Staging-Area entfernen

Die nächsten beiden Abschnitte erläutern, wie Sie mit Ihrer Staging-Area und den Änderungen des Arbeitsverzeichnisses arbeiten. Der angenehme Nebeneffekt ist, dass der Befehl, mit dem Sie den Zustand dieser beiden Bereiche bestimmen, Sie auch daran erinnert, wie Sie Änderungen an ihnen rückgängig machen können. Nehmen wir zum Beispiel an, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen übertragen, aber Sie geben versehentlich git add * ein und stellen sie dann beide in der Staging-Area bereit. Wie können Sie eine der beiden aus der Staging-Area entfernen? Der Befehl git status meldet:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

Direkt unter dem Text „Changes to be committed“, steht, dass man git reset HEAD <file>…​ verwenden soll, um die Staging-Area zu entleeren. Lassen Sie uns also diesem Rat folgen und die Datei CONTRIBUTING.md aus der Staging-Area entfernen:

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Der Befehl klingt etwas merkwürdig, aber er funktioniert. Die Datei CONTRIBUTING.md ist modifiziert und wieder im Status unstaged überführt.

Anmerkung

Es stimmt, dass git reset ein riskanter Befehl sein kann, besonders, wenn Sie das --hard Flag mitgeben. In dem oben beschriebenen Szenario wird die Datei in Ihrem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist.

Im Moment ist dieser Aufruf alles, was Sie über den Befehl git reset wissen müssen. Wir werden viel ausführlicher darauf eingehen, was reset bewirkt und wie man es beherrscht, um wirklich interessante Aufgaben zu erledigen, siehe Kapitel 7 Git Reset.

Änderung in einer modifizierten Datei zurücknehmen

Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei CONTRIBUTING.md nicht behalten wollen? Wie können Sie sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)? Glücklicherweise sagt Ihnen git status, wie Sie das machen können. Im letzten Beispiel sieht die Unstaged-Area so aus:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. Lassen Sie es uns ausführen:

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Wie Sie sehen, wurde die Änderungen rückgängig gemacht.

Wichtig

Es ist sehr wichtig zu begreifen, dass git checkout -- <file> ein riskanter Befehl ist. Alle lokalen Änderungen, die Sie an dieser Datei vorgenommen haben, sind verloren – Git hat diese Datei einfach durch die zuletzt committete oder gestagte Version ersetzt. Verwenden Sie diesen Befehl nur, wenn Sie sich absolut sicher sind, dass Sie diese nicht gespeicherten lokalen Änderungen nicht benötigen.

Wenn Sie die Änderungen, die Sie an dieser Datei gemacht haben, beibehalten möchten, sie aber vorerst aus dem Weg räumen möchten, sollten wir das Stashing und Branching in Kapitel 3 – Git Branching durchgehen; das sind im Allgemeinen die besseren Methoden, um das zu erledigen.

Denken Sie daran, dass alles, was in Git committet wird, fast immer wiederhergestellt werden kann. Sogar Commits, die auf gelöschten Branches lagen oder Commits, die mit einem --amend Commit überschrieben wurden, können wiederhergestellt werden (siehe Kapitel 10 Daten-Rettung für das Wiederherstellen der Daten). Wahrscheinlich werden Sie alles, was Sie verworfen und nie committet haben, nie wieder sehen.

Änderungen mit git restore Rückgängig machen

Git Version 2.23.0 führte einen neuen Befehl ein: git restore. Es ist im Grunde eine Alternative zu git reset, die wir gerade behandelt haben. Ab Git Version 2.23.0 verwendet Git für viele dieser Vorgänge git restore anstelle von git reset.

Lassen Sie uns unsere Schritte wiederholen und die Dinge mit git restore anstelle von git reset rückgängig machen.

Eine Datei mit git restore unstagen

Die nächsten beiden Abschnitte zeigen, wie Sie an Änderungen in Ihrem Staging-Bereich und im Arbeitsverzeichnisses mit git restore arbeiten. Das Schöne daran ist, dass der Befehl, mit dem Sie den Status dieser beiden Bereiche bestimmen, Ihnen auch zeigt, wie Sie Änderungen an ihnen rückgängig machen können. Angenommen, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen festschreiben. Sie geben jedoch versehentlich git add * ein und stellen beide bereit. Wie können sie einen der beiden wieder unstagen? Der Befehl git status zeigt es ihnen:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   CONTRIBUTING.md
	renamed:    README.md -> README

Direkt unter dem Text „Changes to be committed“ steht git restore --staged <file> …​ zum unstagen. Verwenden wir diesen Rat, um die Datei CONTRIBUTING.md zu unstagen:

$ git restore --staged CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   CONTRIBUTING.md

Die Datei CONTRIBUTING.md ist modifiziert und wieder im Status unstaged überführt.

Eine geänderte Datei mit git restore rückgängig machen

Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei CONTRIBUTING.md nicht beibehalten wollen? Wie können Sie sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)? Glücklicherweise sagt Ihnen git status, wie Sie das machen können. Im letzten Beispiel sieht die Unstaged-Area so aus:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   CONTRIBUTING.md

Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. Lassen Sie es uns ausführen:

$ git restore CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README
Wichtig

Es ist wichtig zu verstehen, dass git restore <file> ein gefährlicher Befehl ist. Alle lokalen Änderungen, die Sie an dieser Datei vorgenommen haben, sind weg. Git hat diese Datei durch die zuletzt committete oder gestagte Version ersetzt. Verwenden Sie diesen Befehl nur, wenn Sie sich absolut sicher sind, dass Sie diese nicht gespeicherten lokalen Änderungen nicht benötigen.
scroll-to-top