7.6 Git Tools - Den Verlauf umschreiben

Das Ändern des letzten Commits ist vermutlich der häufigste Grund für die Änderung der Versionshistorie. Du wirst oft zwei wesentliche Änderungen an deinem letzten Commit vornehmen wollen: die Commit-Nachricht oder den eigentlichen Inhalt des Commits ändern, indem du Dateien hinzufügst, entfernst oder modifizierst.

Wenn du lediglich die letzte Commit-Beschreibung ändern willst, ist das einfach:

Der obige Befehl lädt die vorherige Commit-Beschreibung in eine Editorsitzung, in der du Änderungen an der Meldung vornehmen, diese Änderungen speichern und die Sitzung beenden kannst. Wenn du die Nachricht speicherst und schließt, schreibt der Editor einen neuen Commit, der diese aktualisierte Commit-Beschreibung enthält, und macht ihn zu deiner neuen letzten Commit-Beschreibung.

Wenn du andererseits den eigentlichen Inhalt deines letzten Commits ändern willst, funktioniert der Prozess im Prinzip auf die gleiche Weise. Mache zuerst die Änderungen, die du glaubst, vergessen zu haben, stage diese Änderungen und der anschließende git commit --amend ersetzt diesen letzten Commit durch deinen neuen, verbesserten Commit.

Du musst mit dieser Technik vorsichtig sein, da die Änderung den SHA-1 des Commits ändert. Es ist wie ein sehr kleiner Rebase – ändere deinen letzten Commit nicht, wenn du ihn bereits gepusht hast.

Um einen Commit zu ändern, der weiter zurückliegt, musst du komplexeren Werkzeuge nutzen. Git hat kein Tool zum Ändern der Historie, aber du kannst 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 kannst du dann nach jedem Commit pausieren und die Beschreibung ändern, Dateien hinzufügen oder was immer du willst. Du kannst Rebase interaktiv ausführen, indem du die Option -i mit git rebase verwendest. Du musst angeben, wie weit du die Commits umschreiben willst, indem du dem Kommando den Commit nennst, auf den du rebasen willst.

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

Bitte vergiss 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üge keinen Commit ein, den du bereits auf einen zentralen Server gepusht hast. Das wird andere Entwickler verwirren, weil sie eine neue Version der gleichen Änderung übermitteln.

Wenn du diesen Befehl ausführst, erhältst du eine Liste von Commits in deinem Texteditor, die ungefähr so aussieht:

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

Beachte die entgegengesetzte Reihenfolge. Der interaktive Rebase stellt dir ein Skript zur Verfügung, den er ausführen wird. Es beginnt mit dem Commit, den du auf der Kommandozeile angibst (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.

Du musst das Skript so bearbeiten, dass es bei dem Commit anhält, den du bearbeiten willst. Ändere 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, ändere die Datei so, dass sie wie folgt aussieht:

Wenn du speicherst und den Editor verlässt, springt Git zum letzten Commit in dieser Liste zurück und zeigt dir die folgende Meldung an der Kommandozeile an:

Diese Hinweise sagen dir genau, was zu tun ist. Schreibe:

ändere die Commit-Beschreibung und verlasse den Editor. Dann rufe folgenden Befehl auf:

Damit setzt du die anderen beiden Commits automatisch fort und du bist fertig. Falls du „pick“ zum Bearbeiten in mehreren Zeilen zu „edit“ änderst, kannst du diese Schritte für jeden zu bearbeitenden Commit wiederholen. Jedes Mal hält Git an, lässt dich den Commit ändern und fährt fort, sobald du fertig bist.

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

nachher:

Wenn du gespeichert und den Editor verlassen hast, spult Git deinen Branch zum Elternteil dieser Commits zurück, wendet 310154e und dann f7f3f6d an und stoppt dann. Du änderst effektiv die Reihenfolge dieser Commits und entfernst den „Add cat-file“ Commit komplett.

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

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

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

Wenn du das speicherst, hast du 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 du am Ende haben willst. Nehmen wir beispielsweise an, du willst den mittleren Commit deiner drei Commits teilen. Statt „Update README formatting and add blame“ willst du ihn in zwei Commits aufteilen: „Update README formatting“ für die erste und „Add blame“ für die zweite. Du kannst das mit dem rebase -i Skript tun, indem du die Anweisung für den Commit, den du aufteilen willst, in „edit“ änderst:

Wenn das Skript dich dann auf die Befehlszeile zurückführt, setze diesen Commit zurück, übernehmen die zurückgesetzten Änderungen und erstelle daraus mehrere Commits. Wenn du speichern und den Editor verlässt, springt Git zum Elternteil des ersten Commits in deiner Liste zurück, wendet den ersten Commit an (f7f3f6d), wendet den zweiten an (310154e) und führt dich zurück auf die Konsole. Dort kannst du ein kombiniertes Zurücksetzen dieses Commits mit git reset HEAD^ durchführen, was praktisch den Commit rückgängig macht und die modifizierten Dateien unstaged lässt. Jetzt kannst du Dateien so lange stagen und committen, bis du mehrere Commits ausgeführt hast, und danach, wenn du fertig bist, git rebase --continue starten:

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

Dies ändert die SHA-1s der drei jüngsten Commits in deiner Liste. Stelle also sicher, dass kein geänderter Commit in dieser Liste auftaucht, den du bereits in ein gemeinschaftliches Repository verschoben hast. Beachte, 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 du einen Commit entfernen möchtest, kannst du ihn mit dem Skript rebase -i löschen. Füge in der Liste der Commits das Wort „drop“ vor dem Commit ein, den du löschen möchtest (oder lösche 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 du in der Historie deines Repos zurück gehst, 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 du ein solches Rebase teilweise durchläufst und feststellst, dass dies keine gute Idee ist, kannst du jederzeit damit aufhören. Gib git rebase --abort ein und dein Repo wird in den Zustand zurückversetzt, in dem es sich befand, bevor du das Rebase gestartet hast.

Wenn du ein Rebase beendest und feststellst, dass es nicht das ist, was du wolltest, kannst du git reflog verwenden, um eine frühere Version deines Branches wiederherzustellen. Weitere Informationen zum Befehl reflog findest du unter Datenwiederherstellung.

Es gibt noch eine weitere Option zum Überschreiben der Historie, wenn du eine größere Anzahl von Commits auf eine skriptfähige Art und Weise umschreiben musst. Wenn du, zum Beispiel, deine E-Mail-Adresse global änderst oder eine Datei aus jedem Commit entfernen willst. Der Befehl heißt filter-branch und kann große Teile deines Verlaufs neu schreiben. Du solltest ihn deshalb besser nicht verwenden. Es sei denn, dein Projekt ist noch nicht veröffentlicht und andere Leute haben noch keine Arbeiten an den Commits durchgeführt, die du gerade neu schreiben willst. Wie auch immer, er kann sehr nützlich sein. Du wirst ein paar der häufigsten Verwendungszwecke kennenlernen, damit du eine Vorstellung gewinnen kannst, wofür er geeignet ist.