Meine letzte Commit-Nachricht ist falsch oder eine Datei fehlt

Du hast vor einer Minute einen Commit erstellt, und er stimmt nicht. Vielleicht sagt die Nachricht nichts Nützliches aus, oder du wolltest eine Datei aufnehmen und hast sie vergessen. Der Commit liegt bisher nur auf deinem Rechner.

Git kann diesen Commit durch einen besseren ersetzen. Der Haken steckt im Wort ersetzen. In dieser Lektion geht es ebenso darum, wann du das tun solltest, wie darum, wie es geht.

Lesen, was du tatsächlich committet hast

git log
git status

Zwei Probleme: Der neueste Commit hat die Nachricht update, die späteren Lesern nichts sagt. Außerdem liegt packing.txt, eine Liste mit Stiefeln, Karte und Kompass, unverfolgt daneben. Sie hätte mit hinein sollen.

Beides in einem Schritt korrigieren

git commit --amend ersetzt den neuesten Commit durch einen neuen, der aus allem aktuell Bereitgestellten und einer von dir angegebenen Nachricht entsteht.

Lies das noch einmal, denn darin liegt die Falle dieses Befehls: Alles Bereitgestellte kommt hinein, nicht nur die gerade hinzugefügte Datei. Eine Datei, die du vor einer Stunde bereitgestellt und vergessen hast, wird gleich Teil eines Commits, dessen Nachricht nichts über sie sagt.

Gewöhne dir deshalb an, vor dem Ersetzen nachzusehen. Das git status am Anfang dieser Lektion zeigt scratch.tmp nach der vorherigen Lektion sicher als nicht verfolgt und nichts in der Staging-Area. Das ist der sichere Ausgangspunkt. Stelle nur die vergessene Datei bereit und ersetze den Commit:

git add packing.txt
git commit --amend -m "Add the packing list and the ranger note"
git log
git status

git add packing.txt stellt die Datei bereit, genau wie bei einem gewöhnlichen Commit. git commit --amend erstellt dann einen Commit aus dem bereitgestellten Inhalt und verwendet ihn anstelle des vorherigen Commits, statt ihn dahinter anzuhängen. -m gibt die neue Nachricht an, genauso wie bei einem normalen Commit.

git log zeigt jetzt die bessere Nachricht. Die Anzahl der Commits ist nicht gestiegen. git status erwähnt packing.txt nicht mehr, weil die Datei jetzt committet ist, statt unverfolgt herumzuliegen.

git status ist trotzdem nicht leer und soll es auch nicht sein. scratch.tmp ist noch immer als nicht verfolgte Datei vorhanden, genau dort, wo du sie in der vorherigen Lektion hinterlassen hast: Du hast sie aus der Staging-Area genommen, nicht gelöscht. Sie ist nicht zusammen mit packing.txt in den ersetzten Commit gerutscht.

Was dabei zerstört wird und was nicht

Der alte Commit wird nicht bearbeitet. Git bearbeitet keine Commits. Ein neuer mit anderem Inhalt wird erstellt, und dein Branch wird so verschoben, dass er auf ihn zeigt. Kein Branch zeigt mehr auf das Original. Über das Reflog lässt es sich aber noch eine Zeit lang wiederherstellen.

Das ist in zweierlei Hinsicht wichtig. Es erklärt, warum die Commit-Anzahl nicht wächst. Und es erklärt, warum das hier sicher ist: Nichts geht verloren, das du nicht ohnehin ersetzen wolltest. Selbst der aufgegebene Commit ist noch eine Zeit lang auffindbar. Darum geht es in der letzten Lektion dieses Kapitels.

Die eigentliche Grenze betrifft nicht die Sicherheit, sondern andere Menschen:

Ersetze mit amend nur einen Commit, den niemand sonst hat. Sobald jemand deinen Commit besitzt, führt das Ersetzen dazu, dass die andere Person einen Verlauf hat und du einen anderen. Beide müssen dann von Hand wieder in Einklang gebracht werden.

Hier ist der Commit noch privat. Ihn zu ersetzen, ist deshalb passend. Die nächste Lektion behält diese Bedingung eines privaten Verlaufs bei, ändert aber die Aufgabe: den neuesten Commit aus dem Branch entfernen und seine Arbeit behalten.

Als Nächstes: einen privaten Commit zurücknehmen, ohne seine Dateiänderungen zu verwerfen.