Manchmal möchte man die Vergangenheit ändern, und sei es nur, um diesen dämlichen Tippfehler in einer Commit Message zu korrigieren. Das ging bisher bestenfalls im letzten Commit mittel --amend. Seit Version 2.54 kennt Git das (zunächst mal experimentelle) Kommando history, mit dem man auch länger zurückliegende Commits nachträglich bearbeiten kann. Aktuell gibt es zwei Operationen: reword und split.
Mit git history reword <commitid> öffnet man den Editor mit der Commit Message des angegebenen Commits, und kann dort Änderungen vornehmen. Mit git history split <commitid> kann man einen existierenden Commit in zwei Teile aufspalten. Der Befehl geht die Änderungen im bestehenden Commit interaktiv durch, wie man es von git add -p kennt. Die ausgewählten Änderungen werden in einen neuen Commit “abgespalten”.
Aber Vorsicht: Beides verändert eben die Vergangenheit. Das ist einerseits ja gerade das Ziel, kann auf der anderen Seite aber auch für Probleme sorgen.
Denn in Git gilt die “Goldene Regel”, die in unterschiedlichen Formulierungen etwa so lautet: Wenn ein Commit bereits an andere weitergegeben wurde, schraube nachträglich nicht mehr daran herum.
Der Grund ist recht einfach: Jeder Commit hat einen Hash, der als ID fungiert. Dieser Hash wird aus verschiedenen Teilen des Commits gebildet:
- den enthaltenen Änderungen
- der Commit Message
- dem Autor
- dem Parent Commit
Wird einer dieser Bestandteile verändert, ergibt sich ein anderer Hash. Und wenn ein Comit einen anderen Hash hat, ist es aus der Sicht von Git auch ein anderer Commit, der im Zweifel mit dem ursprünglichen Commit nichts mehr zu tun hat. Es ist nicht schwer vorzustellen, dass ein solcher “Identitätswechsel” in einem verteilten Versionierungsystem für großes Durcheinander sorgt.
Also, git history kann ein wertvolles Werkzeug sein, wenn man weiß, wie und wo man es einsetzen kann - und wo besser nicht.
