Unser Git-Workflow für die Entwicklung von WordPress-Themes

Von Konstantin

Git-Branches können verschiedene Arbeitsumgebungen in der Versionsverwaltung repräsentieren, was einen guten Überblick über Projekte sowie direkten Zugriff auf verschiedene Arbeitsstände in diesen ermöglicht.

Aktualisiert am 8. März 2023 3 Kommentare

Die Entwicklung von Themes für WordPress erfolgt typischerweise in mehreren Instanzen, die jeweils spezifische Funktionen im Arbeitsprozess eines Teams haben. Wir haben euch bereits beschrieben, wie wir verschiedene Arbeitsumgebungen in WordPress definieren und verwenden. Um den Überblick über die Projektstände in den Instanzen zu behalten, wenden wir das Prinzip der Arbeitsumgebungen auch in der Versionsverwaltung für unseren Code an. Zusätzlich kommt eine Projektmanagmentsoftware zum Einsatz, mit der wir Aufgaben zuordnen und erfolgte Arbeitsschritte nachvollziehen können.

Git–Branches für verschiedene Projektstände (main, dev, feature)

Als Werkzeug zur Versionsverwaltung benutzen wir die quelloffene Software Git. Pro Projekt erstellen wir ein Repository in Bitbucket, das uns als Git-Host dient. In einem Repository verwalten wir typischerweise nur das von uns erstellte Theme (andere Komponenten, wie WP-Core, Plugins, Datenbank, Uploads etc. handhaben wir mit anderen Werkzeugen).

Analog zu dem dreistufigen Modell der Arbeitsumgebungen haben wir ein dreistufiges Branch-Modell in Git etabliert. Der Branch main entspricht dem Stand auf dem Production-Server, ist also stets der Stand, der öffentlich zugänglichen Version der Website. Der Branch dev repräsentiert den Stand auf dem Development-Server, entspricht also dem aktuellen Entwicklungsstand, mit dem z. Bsp. Kunden ein neues Feature präsentiert werden kann, bevor es in main überführt und auf den Production-Server gespielt wird.

Das Branch-Präfix feature benutzen wir für Neu- und Weiterentwicklungen. Soll also eine neue Funktionalität umgesetzt werden, erfolgt dies in einem von dev abzweigendem Branch, der bspw. feature/new-thing heißt. Die Arbeit an Feature-Branches erfolgt in lokalen Arbeitsumgebungen. Einzelne Schritte werden in Commits verfasst und regelmäßig auf den Git-Host gespielt, so dass aktuelle Änderungen stets für das gesamte Team nachvollziehbar sind. Erst wenn ein Feature lokal getestet wurde, wird es in den dev-Branch überführt und auf den Development-Server gespielt.

Je nach Bedarf werden auch weitere Branches oder Branch-Prefixe verwendet, z. Bsp. config für Konfigurationen. Auf diese Weise sind wir flexibel, aber strukturiert.

Zusammenspiel von Versionsverwaltung und Projektmanagement

Als Projektmanagementwerkzeug benutzen wir Jira. Darin legen wir auf Projektebene für jede Anforderung (»Feature«) eine Aufgabe an, führen dort aber auch Support- und Fehlertickets zusammen. Jede dieser Aufgaben in Jira hat eine ID, die wir zur Kennzeichnung von Branches und Commits in Git benutzen und damit eine Zuordnung von Aufgabe und Umsetzung erreichen. So wird etwa das Ticket »ABC-999« im Branch feature/ABC-999 bearbeitet.

Die Commit-Messages folgen dem Muster <type> <id> <message>. Die Umsetzung von Aufgaben sind vom Typ feature, die Behebung eines Fehlers wird mit fix gepräfixt. Weitere von uns verwendete Commit-Typen sind test, refactor, clean und config. Die ID ist die Ticket-ID. Eine Commit-Meldung für die Umsetzung eine neuen Features sieht also so aus: feature ABC-999 Implement new thing. Dadurch ist die Zuordnung eines Commits zu einer Aufgabe auch später noch unkompliziert möglich. Außerdem können auf diese Weise Bitbucket und Jira zusammengehörige Tasks und Commits in der jeweilegen Benutzeroberfläche anzeigen.

Geschrieben von Konstantin Hanke

Konstantin arbeitet als Webentwickler bei kulturbanause. Seine Hauptaufgabe ist die technische Umsetzung von klaren, soliden und effizienten Webauftritten und Website-Komponenten. Darüber hinaus kümmert er sich um die Wartung, Optimierung und Weiterentwicklung von bestehenden Websites. Sein besonderes Interesse gilt der Idee von quelloffener, freier Software.