Git est l’outil de versioning le plus utilisé au monde, mais sa puissance peut devenir un cauchemar sans conventions claires. Un Git workflow bien défini permet à une équipe de collaborer efficacement, de réduire les conflits de merge et de maintenir un historique lisible. Chez MapWay, nous avons testé plusieurs approches avant de trouver le workflow optimal pour nos projets cartographiques.
Git Flow : le classique
Git Flow, popularisé par Vincent Driessen en 2010, est le workflow le plus structuré. Il utilise deux branches permanentes (main et develop) et trois types de branches temporaires (feature, release, hotfix). Les fonctionnalités sont développées dans des branches feature/* créées à partir de develop, puis fusionnées dans develop via des pull requests. Quand une release est prête, une branche release/* est créée pour les tests finaux avant d’être fusionnée dans main et develop.
Git Flow convient aux projets avec des releases planifiées et des versions multiples en production. Cependant, sa complexité est souvent excessive pour les applications web modernes où le déploiement continu rend obsolète la notion de « release ». Les multiples branches longue durée augmentent le risque de conflits et ralentissent le cycle de livraison.
GitHub Flow : la simplicité
GitHub Flow est radicalement plus simple : une branche main toujours déployable, et des branches de fonctionnalité créées à partir de main. Le workflow se résume en cinq étapes : créer une branche, faire des commits, ouvrir une pull request, discuter et réviser le code, fusionner dans main et déployer automatiquement.
C’est le workflow que nous utilisons chez MapWay pour la majorité de nos projets, y compris TMaps et Houni.tn. Sa simplicité réduit la charge cognitive, accélère les livraisons et s’intègre parfaitement avec notre pipeline CI/CD. Chaque merge dans main déclenche automatiquement les tests, le build et le déploiement en production.
Trunk-Based Development
Le Trunk-Based Development pousse la simplicité encore plus loin : les développeurs commitent directement sur la branche principale (trunk) ou utilisent des branches de très courte durée (moins de 24h). Les fonctionnalités non terminées sont masquées derrière des feature flags. Cette approche, adoptée par Google et Facebook, maximise l’intégration continue mais exige une discipline rigoureuse, une couverture de tests élevée et un système de feature flags mature. Elle est recommandée pour les équipes expérimentées pratiquant le déploiement continu.
Conventions de commits
Des messages de commit clairs et structurés rendent l’historique Git lisible et exploitable. La spécification Conventional Commits propose un format standardisé :
- feat: ajout d’une fonctionnalité (ex: feat: ajouter la recherche d’adresses)
- fix: correction de bug (ex: fix: corriger le calcul de distance sur le méridien)
- docs: modification de documentation
- style: changement de formatage sans impact fonctionnel
- refactor: restructuration de code sans changement fonctionnel
- test: ajout ou modification de tests
- chore: tâches de maintenance (dépendances, CI, config)
Ces conventions permettent la génération automatique de changelogs, le versioning sémantique automatisé (via semantic-release ou release-please) et une lecture rapide de l’historique. Chez MapWay, nous appliquons ces conventions avec un hook pre-commit qui valide le format du message.
Code Review : la clé de la qualité
La code review via les pull requests est l’un des mécanismes les plus efficaces pour maintenir la qualité du code et partager les connaissances dans l’équipe. Nos règles chez MapWay :
- Chaque PR doit être relue par au moins un autre développeur avant fusion
- Les PR doivent être petites et focalisées (moins de 400 lignes modifiées)
- La description de la PR explique le « pourquoi » et pas seulement le « quoi »
- Les tests doivent passer avant que la review ne commence
- Les commentaires de review sont constructifs et expliquent le raisonnement
Gestion des conflits
Les conflits de merge sont inévitables dans un travail d’équipe, mais ils peuvent être minimisés avec de bonnes pratiques :
- Branches courtes : plus une branche vit longtemps, plus elle diverge de main et plus les conflits sont probables. Visez des branches de 1-3 jours maximum.
- Rebase régulier : rebaser votre branche sur main régulièrement intègre les changements des collègues progressivement plutôt qu’en une seule fois.
- Communication : prévenez l’équipe quand vous modifiez des fichiers partagés (configurations, schémas de base de données, interfaces communes).
- Fichiers de lock : ajoutez package-lock.json et yarn.lock au .gitignore si vous utilisez des workspaces, ou commitez-les systématiquement sinon.
Outils complémentaires
Au-delà de Git lui-même, plusieurs outils améliorent le workflow d’équipe. Husky configure des hooks Git (pre-commit, commit-msg) pour valider le code et les messages avant chaque commit. lint-staged n’exécute les linters que sur les fichiers modifiés pour des vérifications rapides. commitlint valide le format des messages de commit. GitHub Actions ou GitLab CI automatisent les vérifications sur chaque pull request. Chez MapWay, cette combinaison d’outils garantit que chaque commit respecte nos standards de qualité.