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.