In der praktischen PHP-Entwicklung kann es oft schwierig sein, Änderungen und Anweisungen zwischen Entwickler:innen und Reviewer nachzuvollziehen. Mit der IDE PhpStorm und ein wenig Hygiene bei der Commit-Erstellung kann der Prozess deutlich vereinfacht werden.
PHP-Entwicklung ist grundsätzlich natürlich mit jedem Text-Editor möglich. Bei großen Projekten, wie sie bei denkwerk Alltag sind, ist es aber wichtig, eine Entwicklungsumgebung samt der Versionierung Git zu verwenden. Das ermöglicht Entwickler:innen, Reviewern und Projektverantwortlichen Code-Ergänzungen und Änderungen. Ein leistungsstarkes Tool hierfür ist PhpStorm, welches wir auch im denkwerk nutzen.
Allerdings ist der Einsatz einer leistungsstarken IDE nicht alles: Git-Commits und ihre Kommentierung sollten besondere Aufmerksamkeit erhalten, um Entwickler:innen die Arbeit an eigenen und fremden Projekten zu erleichtern. PhpStorm bietet dafür vielfältige Möglichkeiten, wie denkwerk Software Developer Miguel Franken im aktuellen TechTalk zusammenfasst.
Grundsätzlich existieren verschiedene Methoden, um Commits und ihre Nachrichten übersichtlich und nachvollziehbar zu gestalten.
„Die Commit History sollte immer eine Geschichte erzählen“, weiß Miguel und gibt Tipps, wie Developer dafür sorgen können, das Commit sauber und nachvollziehbar einzupflegen. Das Anlegen einer sauberen Commit History ist dabei ein entscheidender Faktor – und der Ausgangspunkt für nachvollziehbares Arbeiten im Team.
Deshalb Miguel rät dazu, sogenannte Atomic Commits vorzunehmen: Wenn Entwickler:innen viele Änderungen an mehreren Stellen im Code vornehmen, neigen sie dazu, das große Ganze zu betrachten – und pflegen den gesamten Code als einen Commit. Die Idee hinter Atomic Commits: Jede Änderung ist separat als eigenen Commit zu setzen und zu kommentieren. Gleichzeitig sollen nur solche Commits eingepflegt werden, die auch relevant sind.
Dies hat drei entscheidende Vorteile: Einerseits können Code-Änderungen später besser nachvollzogen werden, andererseits ermöglicht diese Vorgehensweise auch Dritten – etwa Reviewern oder anderen Developern – Änderungen zu verstehen. Gleichzeitig erleichtern Atomic Commits die Suche nach Bugs im Code. Dadurch kommt es aus den verschiedenen Vorgängen automatisch zu einer „sauberen“ Commit History.
Als Unterstützung dieser Technik ist es sinnvoll, Wert auf die Commit Messages zu legen, also die Beschreibung der Änderungen: Hier halten alle Entwickler:innen fest, welche Änderungen sie mit dem jeweiligen Commit durchgeführt haben. Wichtig hierbei: Möglichst präzise und knapp formulieren.
Eine typische Commit Message wäre also „Update X to Y“ oder „Change Color of Element“. Natürlich dürfen die Messages auch komplexer sein, sofern komplexere Änderungen vorliegen. Die Commit-Nachricht muss alle Informationen enthalten, um das Review zu erleichtern.
Um die Änderungen und Nachrichten gut lesbar und nachvollziehbar zu gestalten, ist es zudem sinnvoll, sich an zuvor definierte Konventionen zu halten. Dabei können einerseits allgemeingültige Regeln verwendet werden – etwa die Commit Message im Imperativ zu formulieren. Zusätzlich sollten Entwickler-Teams gemeinsame Richtlinien festlegen: Diese Regeln sorgen dafür, dass alle wichtigen Informationen enthalten sind und das Nachvollziehen der Commits erleichtert wird. Schließlich, so scherzte Miguel über die unterschiedliche Arbeitsweise von Software-Entwicklern, sei „des einen Schönheit des anderen böser Hack.“
Um die Commit History sauber zu halten, bietet die IDE PhpStorm einige praktische Funktionen: So können Commits mittels „Interactive Rebase“ nachträglich geändert, ergänzt, verschoben oder gelöscht werden. Miguel empfiehlt, diese Änderungen lokal vor dem Push durchzuführen: „Nicht pushen, bevor Du mit Deiner Arbeit zufrieden bist.“
Änderungen an Commit Messages sollten mittels sogenannter „Amendments“, also Ergänzungen der Commit Message festgehalten werden. Hier ist es nicht notwendig, Kleinigkeiten wie Rechtschreibkorrekturen der vorherigen Nachricht zu kommentieren. Komplexere Ergänzungen oder Änderungen können aber auf diese Weise ebenfalls festgehalten werden. Dadurch sind Reviewer und Developer jederzeit in der Lage, Code-Änderungen nachzuvollziehen.