Workflow Git pour développeurs PHP : comment arrêter de craindre les conflits et aimer la revue de code
\n\nAvez-vous déjà passé une demi-journée à fusionner des branches pour finalement obtenir une « erreur fatale » en production ? Ou peut-être votre collègue a-t-il accidentellement poussé du code « brut » directement dans master, et vous l'avez appris quand le site est tombé ? Si oui — bienvenue au club. Mais la bonne nouvelle, c'est que 90 % de ces problèmes sont résolus par un workflow Git approprié pour les développeurs PHP.
\n\nDans cet article, nous ne allons pas paraphraser la documentation. Nous allons analyser des scénarios réels : comment organiser les branches, quand utiliser rebase et quand utiliser merge, et comment configurer les processus pour que l'équipe ne se perde pas dans les commits. C'est parti !
\n\nPourquoi « juste git add . && git push » est un mal
\n\nDe nombreux développeurs PHP, surtout au début, utilisent Git comme une « clé USB cloud ». Ils committent tout et n'importe quoi, n'écrivent pas de messages significatifs et poussent directement dans master. Cela fonctionne jusqu'au premier conflit ou jusqu'au moment où il faut annuler une modification.
\n\nUn workflow git php correct doit résoudre trois tâches :
\n- \n
- Isolation des modifications — pour qu'une fonctionnalité ou un correctif de bug ne casse pas le code fonctionnel. \n
- Transparence — pour que tout développeur comprenne ce qui se passe dans le projet. \n
- Automatisation — pour que les tests et les linters s'exécutent avant que le code n'arrive en production. \n
Voyons comment mettre cela en pratique.
\n\nChoisir une stratégie de branchement : Git Flow, GitHub Flow ou quelque chose de personnel ?
\n\nPour les projets PHP, il n'y a pas de réponse unique. Tout dépend de la taille de l'équipe et de la fréquence des versions. Mais il existe deux modèles populaires.
\n\nGit Flow — le classique pour les grands projets
\n\nSi vous travaillez sur une application monolithique avec des versions claires (par exemple, une version par mois), Git Flow est votre choix. Branches principales :
\n- \n
master— uniquement du code stable, correspondant à la production. \n develop— branche d'intégration pour toutes les fonctionnalités. \n feature/*— chaque nouvelle fonctionnalité. \n release/*— préparation de la version. \n hotfix/*— corrections urgentes. \n
Exemple pour un développeur PHP : vous écrivez un module de paiement. Vous créez une branche feature/payment-module à partir de develop. Après terminaison — pull request vers develop. Lorsque suffisamment de fonctionnalités se sont accumulées — vous créez release/2.3.0, où seuls les correctifs de bugs sont effectués. Ensuite, vous fusionnez dans master et develop.
GitHub Flow — pour les itérations rapides
\n\nSi vous avez des microservices ou si vous déployez plusieurs fois par jour, GitHub Flow est plus simple :
\n- \n
main(oumaster) — toujours prêt pour le déploiement. \n - Toute autre branche — pour une fonctionnalité ou un correctif. \n
- Après la pull request et la vérification — fusion immédiate dans
main. \n
Pour PHP, c'est particulièrement pratique lorsque vous avez configuré CI/CD : après la fusion dans main, les tests et le déploiement vers staging ou production sont automatiquement lancés.
\n\nÉcrire des commits significatifs : exemples en PHP
\n\nUn commit n'est pas simplement « sauvegarder ». C'est un document grâce auquel vous et vos collègues reconstituerez l'historique. Utilisez les commits conventionnels :
\n\nfeat: ajout du traitement des paiements via Stripe\nfix: correction de la requête SQL dans le dépôt utilisateur\nrefactor: extraction de la logique de validation dans un trait\n\n\nImaginez maintenant que vous travaillez sur un projet PHP avec Laravel. Supposons que vous ayez ajouté une nouvelle commande Artisan. Quel commit serait utile ?
\n\nfeat: ajout d'une commande artisan pour synchroniser les abonnements expirés\n\n- Création de la commande SyncExpiredSubscriptions\n- Ajout du tag subscription:sync au planificateur\n- Mise à jour du modèle Subscription avec scopeExpired\n\n\nDans un mois, vous pourrez rapidement retrouver quand et pourq