Als Nutzer von GIT als Versionsverwaltung dürfte einem bewusst sein das die Historie nicht
in Stein gemeißelt ist. Commits können sowohl lokal als auch remote auf dem Server verändert
werden. Eine recht verbreitete
Variante dieser Veränderung ist der “Squash”.
Tatsächlich kann man vortrefflich darüber streiten ob es sinnvoll oder vielleicht sogar
gefährlich ist die Historie in einem System zu verändern dessen elementare Aufgabe es ist
eben diese zu bewahren. Für mich ist der Squash in erster Linie ein Mittel um einen Feature-Branch
aufzuräumen, bevor dieser zurück in den master-Branch fließt.
Dabei ist es für mich ein absolutes No-Go blind sämtliche Commits zusammenzuführen nur damit die
Zahl der Commits gering gehalten wird. Wohl aber finde ich es sinnvoll über die Commits zu gehen,
eventuell logisch zusammenhängende Commits zusammenzuführen oder neu zu sortieren. Kleine Fehlercommits
ala “tippfehler korrigiert” interessieren im Nachgang auch niemanden.
Zwiespältig sehe ich das entfernen von Commits die einen Fehler produziert haben. Handelt es sich
um einen Flüchtigkeits- oder Tippfehler dann kann der mMn gerne weg. Bei Denkfehlern kann ein zweiter
Commit mit einer Korrektur und einem Hinweis auf diese vielleicht für einen Reviewer oder interessierten
Codeleser weiter helfen dieses Problem selbst zu vermeiden. Muss man also von Fall zu Fall entscheiden.
Was schon aufgrund technischer Gefahren nicht passieren sollte sind Änderungen der Historie auf dem
Master-Branch, oder auch auf Intergrations-Branches. Diese werden typischerweise von mehreren Entwicklern
verwendet, gar kontinuierlich geliefert und was geliefert wurde sollte sich nach der Lieferung auch
nicht mehr verändern.