Git-Workflow für PHP-Entwickler: Wie man die Produktion nicht zerstört

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Git-Workflow für PHP-Entwickler: Vom Chaos zur Ordnung (und zurück)

\n\n

Haben Sie schon einmal am Freitagabend Code in den Master gepusht und gebetet, dass alles funktioniert? Oder sind Sie auf die Hürde mit composer.lock gestoßen, als nach einem Merge alles kaputtging? Willkommen im Club. Git ist nicht nur ein Versionskontrollsystem, es ist Ihr täglicher Begleiter. Aber ohne den richtigen Workflow wird selbst der coolste PHP-Code zur Kürbisfratze.

\n\n

In diesem Artikel behandeln wir den Git-Workflow für PHP-Entwickler, der wirklich funktioniert: von der Wahl der Branching-Strategie bis zum Deployment. Kein Blabla, nur Code, Beispiele und Lifehacks. Los geht's!

\n\n

1. Strategie wählen: Git Flow vs. Trunk-Based

\n\n

Die Debatte zwischen Git Flow und Trunk-Based-Development ist länger als die Geschichte der PHP-Frameworks. Aber für die meisten PHP-Projekte (insbesondere Legacy-Projekte auf Symfony/Laravel) bleibt Git Flow der Goldstandard. Warum?

\n\n

Klare Isolierung von Features, Releases und Hotfixes.
Kontrolle darüber, was in die Produktion geht.
Arbeit mit Composer – kein ständiges Mergen des Dev-Branches nötig.

\n\n

Aber wenn Sie Microservices und CI/CD auf Steroiden haben, ist Trunk-Based auch eine Option. Wir konzentrieren uns auf die Klassiker.

\n\n

2. Feature-Branch: Ihr Sandkasten

\n\n

Jedes neue Feature bekommt einen eigenen Branch. Der Name sollte aussagekräftig sein: feature/PROJ-123-add-payment-gateway. Kein fix-bug oder new-stuff.

\n\n

Beispiel für den Start:

\n\n

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

\n\n

Vergessen Sie beim Schreiben des Codes nicht den Composer. Wenn Sie eine neue Abhängigkeit hinzufügen, committen Sie composer.json und composer.lock zusammen. Das erspart Kollegen die Frage "Warum funktioniert es bei mir nicht?"

\n\n

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Add predis for caching"

\n\n

Wichtig: Committen Sie nicht vendor/! Fügen Sie es sofort zur .gitignore hinzu.

\n\n

3. Pull Request: Code-Review ohne Schmerz

\n\n

Wenn das Feature fertig ist, erstellen Sie einen PR (oder MR in GitLab) in den develop-Branch. Hier ist eine Checkliste, die dem Reviewer Nerven spart:

\n\n

✅ Code besteht phpcs und phpstan (mindestens Stufe 6).
✅ Tests wurden geschrieben (PHPUnit, Pest).
✅ composer.lock wurde aktualisiert.
✅ Keine Konflikte mit develop.

\n\n

Beispiel für ein CI-Skript (GitHub Actions):

\n\n

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Install dependencies\n        run: composer install --no-interaction --prefer-dist\n      - name: Run PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Run tests\n        run: vendor/bin/phpunit

\n\n

Dieser Workflow für PHP-Entwickler automatisiert die Code-Überprüfung, noch bevor jemand den PR ansieht. Magie, oder?

\n\n

4. Release-Branch: Vorbereitung für die Produktion

\n\n

Wenn genügend Features für ein Release zusammengekommen sind, erstellen Sie release/x.y.z aus develop. Hier beheben Sie Bugs, aktualisieren das Changelog und erhöhen die Version in composer.json.

\n\n

git checkout -b release/1.2.0 develop\n# Bugs beheben, Version aktualisieren\nvim composer.json  # "version": "1.2.0" ändern\ngit commit -am "Bump version to 1.2.0"\n# In master und develop mergen\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Release version 1.2.0"\ngit push origin master --tags

\n\n

Beachten Sie das --no-ff. Dies bewahrt die Branch-Historie, sodass Sie immer wissen, woher der Code kam.