Vue d'ensemble

J'ai développé ce flux de travail après des années passées à gérer des méthodes plus complexes, en gardant tout ce qui fonctionnait et en retravaillant ce qui semblait fragile. Il est né de la frustration de devoir gérer des branches désordonnées, des livraisons chaotiques et des dépôts mal organisés. Ce guide est l'approche pratique et directe que j'aurais aimé avoir.

Pour rendre les choses concrètes, voici le diagramme complet de notre modèle de branches. Revenez-y dès que vous avez besoin de visualiser comment tout s'articule. Ou imprimez-le et mettez-le au-dessus de votre lit.

Les Fondations

Pourquoi ce workflow ? Parce que j'ai vu assez de projets sombrer dans le chaos des branches pour savoir que la simplicité et la discipline sont les seules choses qui fonctionnent. Il ne s'agit pas d'ajouter des règles pour le plaisir ; il s'agit de s'accorder sur un manuel simple qui apporte d'énormes avantages.

• Un seul manuel de jeu : Tout le monde dans l'équipe, du junior fraîchement débarqué au vétéran aguerri, suit les mêmes règles simples. Arrêtez d'improviser, commencez à livrer.
• Protéger main à tout prix : La branche main est sacrée. C'est ce qui peut finir en production. C'est la source de vérité. Le code inachevé, non testé ou non relu ne doit même pas s'en approcher.
• Un historique que vous pouvez réellement lire : En suivant ce processus, votre historique Git devient une histoire propre et linéaire des fonctionnalités livrées et des bogues corrigés. Un revert devrait être une procédure de routine, pas une fouille archéologique qui gâche votre week-end.
• Des livraisons sans drame : Ce processus crée un chemin clair et contrôlé depuis la machine d'un développeur jusqu'à une livraison en production. Les déploiements devraient être ennuyeux, pas une raison de déclencher l'alarme incendie tous les vendredis.

Soyons clairs : les idées présentées ici ne sont pas fondamentalement nouvelles. C'est une variante du "Trunk-Based Development", et il reste fortement inspirée de modèles éprouvés comme GitHub Flow.

"Mais GitHub Flow est trop simpliste ! C'est pour le déploiement continu, ça ne marche pas pour les livraisons et support complexes !"

C'est ce que je croyais aussi. Et vous avez en partie raison. C'est pourquoi j'ai adapté le processus de support et de hotfix du "premier" Gitflow pour qu'il fonctionne de manière transparente avec les outils que nous utilisons réellement aujourd'hui. Ce modèle est conçu pour des plateformes comme GitLab et GitHub qui ont les Branches Protégées et les Merge Requests (MRs) au cœur de leur fonctionnement. Ce ne sont pas seulement des fonctionnalités ; ce sont les gardiens qui garantissent qu'aucun code non approuvé, non testé ou inachevé ne pollue jamais votre branche main sacrée.

Le parcours à venir

Je vais vous guider à travers les scénarios qui constituent 99 % de la vie d'un développeur :

1. ✨ Développement de fonctionnalités : La boucle quotidienne. Votre pain quotidien, fluide et prévisible.
2. ✅ Tâches & Merge Trains : Pour les « gros morceaux » qu'on ne peut pas livrer d'un coup tout seul. Diviser pour régner sans perdre le fil.
3. 🚀 Tagging & Publication : Comment bénir officiellement votre travail, créer une release et laisser le monde en profiter (ou signaler de nouveaux bugs).
4. 💉 Support & Hotfixes : Quand la prod brûle. Un processus calme et contrôlé pour corriger des versions passées sans tout casser.

Faites attention à la manière dont le Versionnement Sémantique et les Commits Conventionnels sont intégrés à chaque étape. Ce ne sont pas seulement de "bonnes idées", c'est le carburant de l'automatisation qui fait tourner tout ce système en douceur. Je vais aussi parsemer quelques astuces de ligne de commande obscures qui vous feront passer pour un magicien et garderont votre historique impeccable.

Ne vous contentez pas de lire, faites-le.

Je n'écris pas des lignes de commande dans toute cette documentation par sadisme. Je vous recommande vivement d'utiliser la ligne de commande en premier lieu. Plus tard, n'hésitez pas à utiliser une interface graphique, mais je conseille fortement de la garder pour la lecture, pas pour fusionner ou rebaser. C'est le seul moyen de comprendre ce que Git fait réellement sous le capot.

Et gardez l'Antisèche des commandes Git sous le coude. Elle résume toutes les commandes pour que vous n'ayez pas à relire toutes mes diatribes juste pour trouver une seule ligne.