Martin Fowler empfiehlt in seinem Buch Refactoring - Improving the Design of Existing Code (de) Refactorings in kleinen Schritten durchzuführen. Sein Ziel ist es den Code immer ausführbar und die Tests grün zu halten. Dafür setzt er auf eine Vielzahl kleiner Commits in seinem lokalen Repository. Wenn er die Änderungen dann ins Remote Repository pusht, führt er sie vorher zusammen. Wie das mit git geht, wollen wir hier kurz beschreiben.
Gehen wir von folgender lokalen git History aus:
Wie wir sehen, haben wir ein paar Refactorings ausgeführt, um die Lesbarkeit unseres Schmutzigen Codestands zu verbessern. Nach jedem dieser Commits waren die Tests grün und mit dem letzten
Commit Ersetzten der for loop durch Stream filter haben wir nun auch einen zufriedenstellenden Codestand erreicht, der uns die Implementierung des eigentlichen Features nun vereinfacht.
Wir entscheiden uns den aktuellen Stand ins Remote Repo zu pushen, wollen zuvor aber die kleinen Commits zu einem größeren Refactoring-Commit zusammenfassen. Dafür wollen wir die Commits
nach dem Schmutzigen Codestand neu ordnen. Das realisieren wir mit einem interactive rebase und geben dafür den Commithash des Commits an:
git rebase -i 7fa4874
Es öffnet sich der eingestellte Editor (bei uns nano) (vor den Commits steht jeweils pick), in dem wir folgende Änderungen vornehmen. Die Commit-Message des ersten Commits wollen wir umbenennen und wählen daher r für reword. Die restlichen Commits wollen wir zusammenschmelzen und wählen daher s für squash. Mit Strg+O lassen sich die Änderungen schreiben (Mit Enter bestätigen).
Strg+X führt uns zum folgenden Fenster, in dem wir die Commit-Message ändern können. Wir ersetzen die ursprüngliche Nachricht "Rename lokale Variable a1 to rechnung" ...
... durch "Refactoring" und schreiben und bestätigen die Änderung mit Strg+O und Enter.
In der Console erscheint die Erfolgsmeldung.
Ein Blick in die History bestätigt den Erfolg*:
git ls
Wir haben gesehen, dass wir mit Hilfe von git rebase recht einfach mehrere Commits unserer lokalen History zu einem Commit zusammenfassen können. Das bietet uns im Rahmen eines Refactorings die nötige Flexibilität und verhindert eine unnötig umfangreiche History auf dem Remote Branch unseres Projekts.
(* Unsere git-Aliasse (wie z.B. "ls") haben wir euch hier vorgestellt)