Flows historiques

1. Git flow avec rebase (variante du Git flow classique)

Processus :

• Branches principales : master (production) et develop (staging)
• Branches de fonctionnalités créées à partir de develop
• Avant de merger une feature, rebase sur develop : git rebase develop feature/x
• Merge dans develop via fast-forward
• Branches hotfix créées depuis master, rebasées, puis mergées dans master et develop

Avantages :

• Historique linéaire et propre
• Facilite l'identification des problèmes par commit
• Évite les commits de merge superflus
• Chaque commit passe les tests avant d'intégrer develop

Inconvénients :

• Réécrit l'historique (problématique pour collaboration)
• Conflits potentiellement complexes lors du rebase
• Nécessite une bonne discipline d'équipe

Flows historiques

1. Flow Hero pure creation
Git flow personnalisé avec rebase

Structure des branches :

• Deux branches principales : develop (staging) et main (production)
• Branches de fonctionnalités créées à partir de develop

Processus de développement :

1. Création de branches features depuis develop
2. Développement sur la branche feature
3. Rebase de la feature sur develop avant intégration
4. Merge de la feature dans develop (staging)

   
   Gestion des correctifs et déploiements :

5. Hotfix appliqués sur develop puis cherry-pick sur main
6. Mise en production via deux méthodes :
   • Si pas de conflits : git merge shacommit (du commit validé en staging)
   • Si conflits dus aux hotfixes/cherry-picks : git reset --hard shacommit sur main

Avantages

• Simplicité structurelle : Seulement deux branches principales à gérer, ce qui réduit la complexité globale
• Historique plus propre sur develop : L'utilisation du rebase pour les features évite les commits de merge et maintient un historique linéaire dans l'environnement de staging
• Réactivité pour les correctifs critiques : Le cherry-pick permet de déployer rapidement des correctifs en production sans attendre un cycle complet
• Flexibilité de déploiement : Deux méthodes disponibles selon la situation (merge ou reset)
• Validation en staging systématique : Toutes les fonctionnalités passent par l'environnement de staging avant production

Inconvénients

• Divergence entre main et develop : Le cherry-pick des hotfixes crée une divergence entre les branches, complexifiant les mises en production ultérieures
• Utilisation du reset --hard risquée : Cette approche est destructive et peut entraîner des pertes d'historique sur la branche main
• Difficulté pour les nouveaux membres : La combinaison de différentes stratégies Git peut être déroutante pour les nouveaux développeurs
• Impossible de protéger la branche main

Nouveau flow

1. Release Flow avec Rebase

Principes fondamentaux

Le Release Flow est basé sur le principe que le code doit toujours être prêt pour une release, avec un déploiement continu des fonctionnalités sur la branche principale, et une séparation claire entre le développement et les versions publiées.

Structure détaillée des branches

1. Branche main (parfois appelée master)
   • Centre de tout le développement
   • Toujours dans un état déployable
   • Reçoit toutes les nouvelles fonctionnalités via rebase et merge
2. Branches de fonctionnalité (feature/nom-fonctionnalité)
   • Créées à partir de main
   • Durée de vie relativement courte (jours à semaines)
   • Rebasées régulièrement sur main pour éviter les divergences
3. Branches de release (release/v1.x.x)
   • Créées à partir de main à un moment précis
   • Représentent une version spécifique du produit
   • Ne reçoivent que des correctifs de bugs, jamais de nouvelles fonctionnalités
4. Branches de hotfix (hotfix/description-bug)
   • Créées à partir de la branche de release concernée
   • Appliquées à la release spécifique
   • Éventuellement portées (cherry-pick) vers main si le bug y est aussi présent

AvantageS

1. Support multi-version robuste
   • Capacité à maintenir plusieurs versions en production simultanément
   • Corrections ciblées sans risquer d'introduire de nouvelles fonctionnalités
2. Clarté de l'historique
   • Chaque version possède son propre historique linéaire
   • Facilite l'audit et la traçabilité des changements
3. Isolation des risques
   • Les branches de release isolent les versions stables du développement actif
   • Minimise les risques lors des déploiements
4. Flexibilité de release
   • Permet des cycles de release prévisibles ou à la demande
   • Compatible avec les contraintes réglementaires strictes
5. Scalabilité pour grandes équipes
   • Workflow adopté par Microsoft pour des projets impliquant des centaines de développeurs
   • Limite les interférences entre équipes

Inconvénients

1. Overhead de maintenance
   • Ressources nécessaires pour maintenir plusieurs versions
   • Synchronisation requise entre correctifs sur différentes branches
2. Risque de drift
   • Les branches de release peuvent diverger significativement de main
   • Complexité croissante des cherry-picks avec le temps
3. Complexité infra​​​
   • Implémentation d'environnement distincts
   • Flow CI et versionning