Gestion de configuration : les stratégies

Mono-branche

  • Une seule branche qui est la branche principale
  • Tous les projets commencent par ça
  • L’intégration continue doit forcer les développeurs à committer du code stable
  • Fonctionne en petite équipe mais nécessite beaucoup de communication et une intégration continue performante

Une branche par équipe

  • En plus de la branche principale, chaque équipe dispose de sa propre branche qui est refusionnée de temps en temps dans la branche principale
  • Cela rend les merges complexes et coûteux donc peu fréquents
  • Cette stratégie a été identifiée comme un anti-pattern

Une branche par fonctionnalité

  • En plus de la branche principale, chaque fonctionnalité dispose de sa propre branche
  • Cela permet de fusionner fréquemment, chaque branche étant à l’échelle d’une user story

GitFlow

Cette stratégie de branchement a été introduite au départ par Vincent Driessen. C’est sur cette stratégie que s’appuie l’ensemble d’extensions git-flow pour Git.

Elle s’articule autour de deux branches principales :

  • master, qui correspond à l’état du code actuellement en production
  • develop, qui correspond aux derniers développements prévus pour passer en production à la livraison suivante

Les branches secondaires sont les suivantes :

  • hotfixes, étroitement liée à la branche master, et sur laquelle sont appliquées les corrections d’anomalies majeures en production
  • release, qui contiennent un état propice aux release candidates, on ne publiera que des bug fixes dessus
  • feature, chacune de ces branches est utilisée pour une fonctionnalité en cours de développement; une fois la fonctionnalité achevée, on l’intègre à la branche develop

A noter que dans un contexte de déploiement continu, les branches de release et de hotfix sont superflues.

git-model@2x

Laisser un commentaire