Git workflow pour développeur PHP : comment ne pas casser la production

Git workflow pour développeur PHP : du chaos à l'ordre (et vice-versa)

Avez-vous déjà poussé du code sur master un vendredi soir, en priant pour que tout fonctionne ? Ou avez-vous marché sur un râteau avec composer.lock, quand tout cassait après un merge ? Bienvenue au club. Git n'est pas seulement un système de contrôle de version, c'est votre daily driver. Mais sans un workflow approprié, même le meilleur code PHP se transforme en citrouille.

Dans cet article, nous allons décortiquer le git workflow pour développeurs PHP qui fonctionne vraiment : du choix de la stratégie de branchement au déploiement. Pas de blabla, seulement du code, des exemples et des astuces. C'est parti !

1. Choisir sa stratégie : Git Flow vs. Trunk-Based

Le débat entre git flow et le trunk-based development est plus long que l'histoire des frameworks PHP. Mais pour la plupart des projets PHP (surtout les legacy sur Symfony/Laravel), Git Flow reste la référence. Pourquoi ?

\n
• Isolation claire des fonctionnalités, releases et hotfixs.
\n
• Contrôle sur ce qui part en production.
\n
• Travail avec composer — pas besoin de merger la branche dev à chaque fois.
\n

Mais si vous avez des micro-services et du CI/CD sous stéroïdes, le trunk-based est aussi une option. Nous allons nous concentrer sur le classique.

2. Feature Branch : votre bac à sable

Chaque nouvelle fonctionnalité — une branche dédiée. Le nom doit être explicite : feature/PROJ-123-add-payment-gateway. Pas de fix-bug ou new-stuff.

Exemple de démarrage :

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

Pendant que vous écrivez du code, n'oubliez pas composer. Si vous ajoutez une nouvelle dépendance, commitez composer.json et composer.lock ensemble. Cela évitera à vos collègues de se demander "pourquoi ça ne marche pas chez moi ?"

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

Important : ne commitez pas vendor/ ! Ajoutez-le dans .gitignore dès le départ.

3. Pull Request : la revue de code sans douleur

Quand la fonctionnalité est prête, créez une PR (ou MR dans GitLab) vers develop. Voici une checklist qui épargnera les nerfs du relecteur :

\n
• ✅ Le code passe phpcs et phpstan (niveau minimum 6).
\n
• ✅ Des tests sont écrits (PHPUnit, Pest).
\n
• ✅ composer.lock est mis à jour.
\n
• ✅ Pas de conflits avec develop.
\n

Exemple de script CI (GitHub Actions) :

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

Ce workflow pour développeurs PHP automatise la vérification du code avant même que quelqu'un ne regarde la PR. Magique, non ?

4. Branche de release : préparation pour la production

Quand suffisamment de fonctionnalités sont accumulées pour une release, créez release/x.y.z à partir de develop. Ici, vous corrigez les bugs, mettez à jour le changelog, et incrémentez la version dans composer.json.

git checkout -b release/1.2.0 develop\n# correction de bugs, mise à jour de la version\nvim composer.json  # on change "version": "1.2.0"\ngit commit -am "Bump version to 1.2.0"\n# on merge dans master et develop\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

Notez l'option --no-ff. Cela préserve l'historique des branches, pour que vous sachiez toujours d'où vient le code.