Ich habe etwas committet, das kein Commit sein sollte

Du hast etwas committet, das überhaupt kein Commit hätte werden sollen. Diesmal geht es weder um eine falsche Nachricht noch um eine Änderung, die später rückgängig gemacht werden soll: Der Commit selbst war ein Fehler, und du möchtest, dass er nicht mehr existiert. Niemand sonst hat ihn.

Amend würde ihn durch einen anderen Commit ersetzen. Du möchtest aber keinen anderen Commit. Du möchtest einen weniger.

Zuerst den Fehler machen

Im Repository liegt die Notizdatei scratch.tmp mit zwei persönlichen Erinnerungen. Committe sie so, als hättest du nicht aufgepasst:

git add scratch.tmp
git commit -m "wip"
git log

git add scratch.tmp stellt die Datei bereit, unabhängig davon, ob sie schon bereitgestellt war. Das funktioniert also gleich, egal wie du zu dieser Lektion gekommen bist. git log zeigt jetzt einen Commit namens wip mit einer privaten Aufgabenliste. Sie sollte überhaupt nicht im Projektverlauf stehen.

Den Branch zurücksetzen

Deine Entwicklungslinie hat einen Namen, main. Dieser Name markiert ihren neuesten Commit. git reset verschiebt diese Markierung. Setze sie um einen Commit zurück, und der Commit wip gehört nicht mehr zu deinem Verlauf:

git reset --soft HEAD~1
git log
git status

Dieser Name heißt Branch. In Kapitel 5 wird das genauer erklärt. Hier brauchst du nur den Teil, von dem reset abhängt: Der Name markiert einen Commit. Wenn du den Namen verschiebst, ändert sich, welche Commits dein Verlauf enthält.

HEAD~1 bedeutet „ein Commit vor meinem jetzigen Stand“. --soft ist der wichtige Teil: Es verschiebt diesen Namen und sonst nichts. Deine Dateien werden nicht angefasst. Alles, was der zurückgenommene Commit enthielt, bleibt in der Staging-Area liegen und kann bei Bedarf erneut committet werden.

git log führt wip nicht mehr auf. git status zeigt scratch.tmp wieder als bereitgestellt, genau wie vor dem Commit. Du bist zurück bei der Entscheidung, nicht darüber hinaus.

Beende die Arbeit, indem du die Datei von der Liste nimmst, wie zuvor in diesem Kapitel:

git restore --staged scratch.tmp
git status

Die drei Varianten von reset und die gefährliche

In der hier verwendeten Form zum Verschieben von Commits bewegt git reset den Branch-Zeiger. Die Varianten unterscheiden sich darin, was sie darüber hinaus verändern:

• --soft verschiebt nur den Zeiger. Deine Änderungen bleiben bereitgestellt. Nichts geht verloren.

• --mixed, die Voreinstellung ohne angegebene Option, verschiebt den Zeiger und setzt die Staging-Area auf den Zielcommit zurück. In diesem Fall mit HEAD~1 sind die Änderungen des zurückgenommenen Commits danach nicht mehr bereitgestellt. Deine Dateien behalten ihren Inhalt. Nichts geht verloren, aber du musst diese Änderungen erneut bereitstellen.

• --hard verschiebt den Zeiger, setzt die Staging-Area zurück und überschreibt die verfolgten Dateien passend dazu. Bereitgestellte oder noch nicht bereitgestellte Änderungen an verfolgten Dateien sind weg. Nicht verfolgte Dateien bleiben normalerweise erhalten. Git kann aber eine entfernen, wenn sie einen verfolgten Pfad blockiert.

Lies den letzten Punkt zweimal. git reset --hard kann verfolgte Arbeit zerstören, von der du keine Kopie hast. Der Befehl ist nicht verboten und durchaus nützlich. Führe ihn aber erst aus, nachdem du git status gelesen und entschieden hast, dass jede bereitgestellte oder noch nicht bereitgestellte Bearbeitung an verfolgten Dateien verworfen werden darf.

Mit dem Commit, von dem du dich zurückgesetzt hast, verhält es sich anders. Er ist nicht gelöscht, sondern nur nicht mehr referenziert. Darum geht es in der letzten Lektion dieses Kapitels.

Wann du das nicht verwenden solltest

Reset entfernt einen Commit aus deinem Branch. Wenn jemand anderes diesen Commit bereits hat, enthält der andere Verlauf ihn noch, deiner aber nicht mehr. Beide müssen dann von Hand wieder in Einklang gebracht werden.

Nimm einen Commit mit reset nur zurück, solange er noch privat ist.

Hier hast du den Commit wip vor wenigen Sekunden selbst in deinem eigenen Repository erstellt. Das ist der sichere Fall. Die nächste Lektion behandelt den anderen.

Als Nächstes: derselbe Fehler, nur hat jemand anderes den Commit bereits.