Git
Chapters ▾ 2nd Edition

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

Ungewollte Änderungen rückgängig machen

Zu jeder Zeit können Sie eine Änderung rückgängig machen. Hier werden wir einige grundlegende Werkzeuge besprechen, die zum Widerrufen von gemachten Änderungen dienen. Seien Sie vorsichtig, denn man kann nicht immer alle diese Annullierungen rückgängig machen. Das ist einer der wenigen Bereiche in Git, in denen Sie etwas 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, einige Dateien hinzuzufügen, oder wenn Sie Ihre Commit-Nachricht durcheinander bringen. Wenn Sie den Commit erneut ausführen möchten, nehmen Sie die zusätzlichen Änderungen vor, die Sie vergessen haben, stellen Sie sie bereit (engl. stage) und committen Sie 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.

Note

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, der nicht in Ihrem Repository-Verlauf auftauchen wird.

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, vergesssen, eine Datei hinzuzufügen“ oder „Verdammt, einen Tippfehler im letzten Commit behoben“ zu überladen.

Eine Datei aus der Staging Area entnehmen

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 „Changes to be committed“ Text, 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 wurde modifiziert, aber erneut unstaged.

Note

Es ist wahr, 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 leicht wieder ändern – sie wieder so zurücksetzen, 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 auch, 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

Es erklärt Ihnen ziemlich eindeutig, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. Lasst Sie uns machen, was da steht:

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

    renamed:    README.md -> README

Sie können erkennen, dass die Änderungen rückgängig gemacht wurden.

Important

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 hinfällig – Git hat diese Datei einfach durch die zuletzt committete Version ersetzt. Verwenden Sie diesen Befehl niemals, es sei denn, Sie sind sich absolut sicher, dass Sie diese ungesicherten lokalen Änderungen nicht wünschen.

Wenn Sie die Änderungen, die Sie an dieser Datei gemacht haben, beibehalten möchten, sie aber vorerst noch nicht vornehmen 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 committed 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). Allerdings wird alles, was Sie verloren haben und das nie committed wurde, wahrscheinlich nie wieder gesehen werden.