Git-Workflow für PHP-Entwickler: Vom Chaos zum sauberen Code

Git-Workflow für PHP-Entwickler: Wie Sie Konflikte nicht mehr fürchten und Code-Review lieben lernen

Haben Sie schon einmal einen halben Tag mit dem Zusammenführen von Branches verbracht, um am Ende einen „fatalen Fehler“ in der Produktion zu erhalten? Oder hat Ihr Kollege versehentlich „rohen“ Code direkt in master gepusht, und Sie haben es erst erfahren, als die Website abstürzte? Wenn ja – willkommen im Club. Die gute Nachricht ist jedoch, dass 90 % solcher Probleme durch einen richtigen Git-Workflow für PHP-Entwickler gelöst werden.

In diesem Artikel werden wir nicht die Dokumentation nacherzählen. Wir werden reale Szenarien durchgehen: wie man Branches organisiert, wann man Rebase und wann Merge verwendet, und wie man Prozesse so einrichtet, dass das Team sich nicht in Commits verheddert. Los geht's!

Warum „einfach git add . && git push“ böse ist

Viele PHP-Entwickler, besonders am Anfang, nutzen Git wie einen „Cloud-USB-Stick“. Sie committen alles durcheinander, schreiben keine aussagekräftigen Nachrichten und pushen direkt in master. Das funktioniert genau bis zum ersten Konflikt oder bis zu dem Moment, in dem eine Änderung rückgängig gemacht werden muss.

Ein richtiger Git-Workflow PHP sollte drei Aufgaben lösen:

\n
• Isolation von Änderungen – damit ein Feature oder Bugfix den funktionierenden Code nicht zerstört.
\n
• Transparenz – damit jeder Entwickler versteht, was im Projekt passiert.
\n
• Automatisierung – damit Tests und Linter ausgeführt werden, bevor der Code in die Produktion gelangt.
\n

Schauen wir uns an, wie das in der Praxis umgesetzt wird.

Branching-Strategie wählen: Git Flow, GitHub Flow oder etwas Eigenes?

Für PHP-Projekte gibt es keine einzig richtige Antwort. Alles hängt von der Teamgröße und der Release-Häufigkeit ab. Aber es gibt zwei beliebte Modelle.

Git Flow – Klassiker für große Projekte

Wenn Sie an einer monolithischen Anwendung mit klaren Versionen arbeiten (z. B. ein Release pro Monat), ist Git Flow Ihre Wahl. Die Hauptbranches:

\n
• master – nur stabiler Code, der der Produktion entspricht.
\n
• develop – Integrationsbranch für alle Features.
\n
• feature/* – jedes neue Feature.
\n
• release/* – Vorbereitung auf ein Release.
\n
• hotfix/* – dringende Korrekturen.
\n

Beispiel für einen PHP-Entwickler: Sie schreiben ein Zahlungsmodul. Sie erstellen einen Branch feature/payment-module von develop. Nach Abschluss – ein Pull-Request in develop. Wenn genügend Features zusammengekommen sind – erstellen Sie release/2.3.0, wo nur Bugfixes vorgenommen werden. Dann mergen Sie in master und develop.

GitHub Flow – für schnelle Iterationen

Wenn Sie Microservices haben oder mehrmals täglich deployen, ist GitHub Flow einfacher:

\n
• main (oder master) – immer bereit zum Deployment.
\n
• Jeder andere Branch – für ein Feature oder einen Bugfix.
\n
• Nach Pull-Request und Überprüfung – sofort in main mergen.
\n

Für PHP ist das besonders praktisch, wenn Sie CI/CD eingerichtet haben: Nach dem Merge in main werden automatisch Tests und Deployment auf Staging oder Produktion gestartet.

Aussagekräftige Commits schreiben: Beispiele in PHP

Ein Commit ist nicht einfach „speichern“. Es ist ein Dokument, anhand dessen Sie und Ihre Kollegen die Historie wiederherstellen werden. Verwenden Sie Conventional Commits:

feat: add payment processing via Stripe\nfix: correct SQL query in user repository\nrefactor: extract validation logic to trait\n

Stellen Sie sich nun vor, Sie arbeiten an einem PHP-Projekt mit Laravel. Angenommen, Sie haben einen neuen Artisan-Befehl hinzugefügt. Welcher Commit wäre nützlich?

feat: add artisan command to sync expired subscriptions\n\n- Created SyncExpiredSubscriptions command\n- Added subscription:sync tag to schedule\n- Updated Subscription model with scopeExpired\n

In einem Monat werden Sie schnell finden können, wann und warum