Les workflows Git, sans bullshit

J’ai bossé avec des équipes de 3 personnes et des équipes de 50. Le workflow Git, c’est souvent là que ça frotte. Pas parce que c’est compliqué. Parce que le bon choix dépend tellement du contexte qu’il n’y a pas de réponse universelle.

Quatre approches existent. Chacune a sa logique. Chacune répond à un besoin différent.

Le workflow linéaire, c’est le premier réflexe. Tout le monde push sur main. Pas de branches. Pas de pull requests. Ça marche bien quand tu es seul sur un side project un dimanche après-midi. À plusieurs, ça devient vite sportif. Les conflits s’accumulent. Les bugs peuvent filer en prod. J’ai vu une startup perdre une journée entière à démêler un merge compliqué. Pas leur faute. Juste un workflow qui n’était plus adapté à leur taille.

• Pertinent pour : projets perso, prototypes, POC
• Montre ses limites : dès qu’il y a une équipe

GitFlow, c’est l’approche structurée. Des branches partout. Main, develop, feature, release, hotfix. Un schéma qui ressemble à un plan de métro.

Il faut remettre les choses dans leur contexte. GitFlow date de 2010. À l’époque, les cycles de release duraient des mois. Les équipes géraient plusieurs versions en parallèle. Dans ce monde-là, GitFlow était une vraie solution. Rigoureuse. Prévisible.

Le souci, c’est qu’il a été adopté par défaut, même dans des contextes où il n’apportait rien. J’ai vu des équipes passer un temps fou à gérer leurs branches au lieu de shipper du code. Des features bloquées dans develop pendant des semaines. Plus personne ne savait ce qui allait partir en prod.

Si tu déploies toutes les deux semaines ou en continu, GitFlow ajoute de la friction sans contrepartie. Mais pour des projets avec versions multiples en maintenance, il reste pertinent.

• Pertinent pour : gros projets avec versions multiples en parallèle, cycles de release longs
• Souvent surdimensionné pour : équipes agiles, déploiement continu

Le forking workflow, c’est le standard open source. Chaque contributeur fork le repo, bosse dans son coin, propose une PR. Linux, Kubernetes, tous les gros projets open source fonctionnent comme ça.

C’est logique dans ce contexte. Tu ne donnes pas l’accès en écriture à des inconnus. En entreprise, avec une équipe fixe qui se fait confiance, ça ajoute des étapes sans réel bénéfice. Mais certaines organisations l’utilisent pour des raisons de compliance ou de séparation des environnements. Chaque contexte a ses contraintes.

• Pertinent pour : projets open source avec contributeurs externes, contextes réglementés
• Souvent superflu pour : équipes internes de confiance

GitHub Flow, c’est ce que je recommande le plus souvent. Une branche main. Elle est toujours déployable. Pour chaque feature, tu crées une branche. Tu bosses. Tu ouvres une PR. Review. Merge. Déploie.

Simple. Efficace. Une équipe peut être opérationnelle en quelques jours.

Les avantages concrets :

• Moins de branches à gérer
• Moins de conflits
• Reviews systématiques sur chaque PR
• Main toujours propre, toujours déployable
• Compatible avec le déploiement continu

J’ai accompagné une équipe de 8 développeurs qui utilisait GitFlow. Ils passaient 20% de leur temps à gérer leurs branches. Leur choix initial se comprenait, ils avaient suivi les “best practices” de l’époque. Après migration sur GitHub Flow, ce temps est tombé à quasi zéro. Ils ont pu sortir des features plus vite. Les bugs en prod ont diminué parce que chaque PR était reviewée.

Le prérequis : une bonne CI. Si tu merges dans main, ça part en prod. Donc les tests doivent passer. Le linting doit être clean. Les checks de sécurité aussi.

Mon retour d’expérience : GitHub Flow couvre la majorité des besoins que je rencontre. GitFlow se justifie dans des cas spécifiques. Le linéaire convient aux projets solo. Le forking a sa place dans l’open source et certains contextes enterprise.

Le meilleur workflow, c’est celui que ton équipe comprend et applique. Un GitFlow approximatif fera plus de dégâts qu’un workflow simple bien maîtrisé. Mon conseil : commence simple. Complexifie seulement quand tu ressens vraiment les limites. Pas avant.