7.6 Git Tools - Den Verlauf umschreiben

Das Ändern des letzten Commits ist vermutlich der häufigste Grund für die Neufassung der Versionsgeschichte. Sie werden oft zwei wesentliche Änderungen an Ihrem letzten Commit vornehmen wollen: einfach die Commit-Beschreibung ändern oder den eigentlichen Inhalt des Commits ändern, indem Sie Dateien hinzufügen, entfernen oder modifizieren.

Wenn Sie lediglich die letzte Commit-Beschreibung ändern wollen, ist das einfach:

Der obige Befehl lädt die vorherige Commit-Beschreibung in eine Editorsitzung, in der Sie Änderungen an der Meldung vornehmen, diese Änderungen speichern und die Sitzung beenden können. Wenn Sie die Nachricht speichern und schließen, schreibt der Editor einen neuen Commit, der diese aktualisierte Commit-Beschreibung enthält, und macht ihn zu Ihrer neuen letzten Commit-Beschreibung.

Wenn Sie andererseits den eigentlichen Inhalt Ihrer letzten Übertragung ändern wollen, funktioniert der Prozess im Prinzip auf die gleiche Weise – machen Sie zuerst die Änderungen, die Sie glauben, vergessen zu haben, stagen Sie diese Änderungen und der anschließende git commit --amend ersetzt diesen letzten Commit durch Ihren neuen, verbesserten Commit.

Sie müssen mit dieser Technik vorsichtig sein, da die Änderung den SHA-1 des Commits ändert. Es ist wie ein sehr kleiner Rebase – ändern Sie Ihren letzten Commit nicht, wenn Sie ihn bereits gepusht haben.

Um einen Commit zu ändern, der weiter zurückliegt, müssen Sie zu komplexeren Werkzeugen wechseln. Git hat kein Tool zum Ändern der Historie, aber Sie können das Rebase-Werkzeug verwenden, um eine Reihe von Commits auf den HEAD zu übertragen, auf dem sie ursprünglich basieren, anstatt sie auf einen anderen zu verschieben. Mit dem interaktiven Rebase-Werkzeug können Sie dann nach jedem Commit pausieren und die Beschreibung ändern, Dateien hinzufügen oder was immer Sie wollen. Sie können Rebase interaktiv ausführen, indem Sie die Option -i mit git rebase verwenden. Sie müssen angeben, wie weit Sie die Commits umschreiben wollen, indem Sie dem Kommando den Commit nennen, auf den Sie umbasen wollen.

Wenn Sie zum Beispiel die letzten drei Commit-Beschreibungen oder eine der Commit-Beschreibungen in dieser Gruppe ändern wollen, geben Sie als Argument für git rebase -i das Elternteil der letzten Commit-Beschreibung, die Sie bearbeiten wollen, an (HEAD~2^ oder HEAD~3). Es ist vielleicht einfacher, sich die ~3 zu merken, weil Sie versuchen, die letzten drei Commits zu bearbeiten. Bedenken Sie aber, dass Sie eigentlich vier Commits angeben müssen, den Elternteil des letzten Commits, den Sie bearbeiten wollen:

Bitte vergessen Sie nicht, dass es sich hierbei um einen Rebasing-Befehl handelt – jeder Commit im Bereich HEAD~3..HEAD mit einer geänderten Beschreibung und allen seinen Nachfolgern wird neu geschrieben. Fügen Sie keinen Commit ein, den Sie bereits auf einen zentralen Server gepusht haben – das wird andere Entwickler verwirren, weil sie eine neue Version der gleichen Änderung übermitteln.

Wenn Sie diesen Befehl ausführen, erhalten Sie eine Liste von Commits in Ihrem Texteditor, die ungefähr so aussieht:

Es ist wichtig zu erwähnen, dass diese Commits in der umgekehrten Reihenfolge aufgelistet werden, als Sie sie normalerweise mit dem log Befehl sehen. Wenn Sie ein log ausführen, sehen Sie etwas wie das hier:

Beachten Sie die entgegengesetzte Reihenfolge. Das interaktive Rebase stellt Ihnen ein Skript zur Verfügung, das es ausführen wird. Es beginnt mit dem Commit, den Sie auf der Kommandozeile angeben (HEAD~3) und gibt die Änderungen, die in jedem dieser Commits eingeführt wurden, von oben nach unten wieder. Es listet die ältesten oben auf, nicht die neuesten, weil es die ersten sind, die es wiedergibt.

Sie müssen das Skript so bearbeiten, dass es bei dem Commit anhält, den Sie bearbeiten wollen. Ändern Sie dazu das Wort ‚pick‘ in das Wort ‚edit‘ für jeden Commit, nach dem das Skript anhalten soll. Um beispielsweise nur die dritte Commit-Beschreibung zu ändern, ändern Sie die Datei so, dass sie wie folgt aussieht:

Wenn Sie speichern und den Editor verlassen, springt Git zum letzten Commit in dieser Liste zurück und zeigt Ihnen die folgende Meldung an der Kommandozeile an:

Diese Hinweise sagen Ihnen genau, was zu tun ist. Schreiben Sie:

ändern Sie die Commit-Beschreibung und verlassen Sie den Editor. Dann rufen Sie folgenden Befehl auf:

Damit setzen Sie die anderen beiden Commits automatisch fort und Sie sind fertig. Falls Sie „pick“ zum Bearbeiten in mehreren Zeilen zu „edit“ ändern, können Sie diese Schritte für jede zu bearbeitenden Commit wiederholen. Jedes Mal hält Git an, lässt Sie den Commit ändern und fährt fort, sobald Sie fertig sind.

Sie können interaktive Rebases auch verwenden, um Commits neu anzuordnen oder ganz zu entfernen. Wenn Sie unten den „Add cat-file“ Commit entfernen und die Reihenfolge ändern wollen, in der die anderen beiden Commits aufgeführt werden, können Sie das Rebase-Skript so anpassen (vorher):

nachher:

Wenn Sie gespeichert und den Editor verlassen haben, blättert Git Ihren Branch zum Elternteil dieser Commits zurück, wendet 310154e und dann f7f3f6d an und stoppt dann. Sie ändern effektiv die Reihenfolge dieser Commits und entfernen den „Add cat-file“ Commit komplett.

Es ist auch möglich, eine Reihe von Commits zu erfassen und sie mit dem interaktiven Rebasing-Werkzeug zu einem einzigen Commit zusammenzufassen. Das Skript fügt hilfreiche Anweisungen in die Rebasemeldung ein:

Wenn Sie statt „pick“ oder „edit“ „squash“ angeben, wendet Git sowohl diese Änderung als auch die Änderung direkt davor an und lässt Sie die Commit-Beschreibungen zusammenfügen. Wenn Sie also einen einzelnen Commit aus diesen drei Commits machen wollen, müssen Sie das Skript wie folgt anpassen:

Wenn Sie speichern und den Editor schließen, wendet Git alle drei Änderungen an und öffnet dann wieder den Editor, um die drei Commit-Beschreibungen zusammenzuführen:

Wenn Sie das speichern, haben Sie einen einzigen Commit, der die Änderungen aller drei vorherigen Commits einbringt.

Das Aufteilen eines Commits macht einen Commit rückgängig und stagt dann partiell so viele Commits, wie Sie am Ende haben wollen. Nehmen wir beispielsweise an, Sie wollten den mittleren Commit Ihrer drei Commits teilen. Statt „Update README formatting and add blame“ wollen Sie ihn in zwei Commits aufteilen: „Update README formatting“ für die erste und „Add blame“ für die zweite. Sie können das mit dem rebase -i Skript tun, indem Sie die Anweisung für den Commit, den Sie aufteilen wollen, in „edit“ ändern:

Wenn das Skript Sie dann auf die Befehlszeile zurückführt, setzen Sie diesen Commit zurück, übernehmen die zurückgesetzten Änderungen und erstellen daraus mehrere Commits. Wenn Sie speichern und den Editor verlassen, springt Git zum Elternteil des ersten Commits in Ihrer Liste zurück, wendet den ersten Commit an (f7f3f6d), wendet den zweiten an (310154e) und lässt Sie auf der Konsole stehen. Dort können Sie ein kombiniertes Zurücksetzen dieses Commits mit git reset HEAD^ durchführen, was praktisch den Commit rückgängig macht und die modifizierten Dateien unberührt (engl. unstaged) lässt. Jetzt können Sie Dateien so lange stagen und committen, bis Sie mehrere Commits ausgeführt haben, und danach, wenn Sie fertig sind, git rebase --continue starten:

Git wendet den letzten Commit (a5f4a0d) im Skript an, und Ihr Verlauf sieht dann so aus:

Dies ändert die SHA-1s der drei jüngsten Commits in Ihrer Liste, stellen Sie also sicher, dass kein geänderter Commit in dieser Liste auftaucht, den Sie bereits in ein gemeinschaftliches Repository verschoben haben. Beachten Sie, dass der letzte Commit (f7f3f6d) in der Liste nicht geändert wurde. Trotzdem wird dieser Commit im Skript angezeigt, da er als „pick“ markiert war und vor jeglichen Rebase-Änderungen angewendet wurde. Git lässt den Commit unverändert.

Wenn Sie ein Commit entfernen möchten, können Sie es mit dem Skript rebase -i löschen. Fügen Sie in der Liste der Commits das Wort „drop“ vor dem Commit ein, das Sie löschen möchten (oder löschen Sie einfach diese Zeile aus dem Rebase-Skript):

Aufgrund der Art und Weise, wie Git Commit-Objekte erstellt, werden beim Löschen oder Ändern eines Commits alle darauf folgenden Commits neu geschrieben. Je weiter Sie in der Historie Ihres Repos zurück gehen, desto mehr Commits müssen neu erstellt werden. Dies kann zu vielen Mergekonflikten führen, wenn es viele Commits in der Historie gibt, die von dem gerade gelöschten abhängen.

Wenn Sie eine solche Rebase teilweise durchlaufen und feststellen, dass dies keine gute Idee ist, können Sie jederzeit damit aufhören. Geben Sie git rebase --abort ein und Ihr Repo wird in den Zustand zurückversetzt, in dem es sich befand, bevor Sie das Rebase gestartet haben.

Wenn Sie eine Rebase beenden und feststellen, dass es nicht das ist, was Sie wollten, können Sie git reflog verwenden, um eine frühere Version Ihres Branches wiederherzustellen. Weitere Informationen zum Befehl reflog finden Sie unter Datenwiederherstellung.

Es gibt noch eine weitere Option zum Überschreiben der Historie, wenn Sie eine größere Anzahl von Commits auf eine skriptfähige Art und Weise umschreiben müssen – wenn Sie, zum Beispiel, Ihre E-Mail-Adresse global ändern oder eine Datei aus jedem Commit entfernen wollen. Der Befehl heißt filter-branch und kann große Teile Ihres Verlaufs neu schreiben. Sie sollten ihn deshalb besser nicht verwenden. Es sei denn, Ihr Projekt ist noch nicht veröffentlicht und andere Leute haben noch keine Arbeiten an den Commits durchgeführt, die Sie gerade neu schreiben wollen. Wie auch immer, er kann sehr nützlich sein. Sie werden ein paar der häufigsten Verwendungszwecke kennen lernen, damit Sie eine Vorstellung gewinnen können, wofür er geeignet ist.