La réponse dépend de la taille de votre équipe et de la qualité de votre contrôle de code source et de la possibilité de fusionner correctement des ensembles de modifications complexes. Par exemple, dans le contrôle de source de branche complet comme CVS ou SVN, la fusion peut être difficile et vous pourriez être mieux avec le premier modèle, tandis que si vous utilisez un système plus complexe comme IBM ClearCase et avec une plus grande taille d'équipe, vous pourriez être meilleur avec le second modèle ou une combinaison des deux.
Personnellement, je séparerais le modèle de branche de fonctionnalité, où chaque fonctionnalité principale est développée sur une branche distincte, avec des sous-branches de tâche pour chaque changement effectué par un développeur individuel. Au fur et à mesure que les fonctionnalités se stabilisent, elles sont fusionnées avec le tronc, que vous gardez raisonnablement stable et en réussissant tous les tests de régression à tout moment. Alors que vous approchez de la fin de votre cycle de publication et que toutes les branches de fonctionnalités fusionnent, vous stabilisez et branchez une branche du système de publication sur laquelle vous ne faites que des corrections de bogues de stabilité et des backports nécessaires, tandis que le tronc est utilisé pour le développement de la prochaine version et vous à nouveau bifurquez pour de nouvelles branches de fonctionnalités. Etc.
De cette façon, le tronc contient toujours le dernier code, mais vous parvenez à le garder raisonnablement stable, en créant des étiquettes stables (balises) sur les changements majeurs et les fusions de fonctionnalités, les branches de fonctionnalités sont un développement rapide avec une intégration continue et des sous-branches de tâches individuelles peuvent être souvent actualisé à partir de la branche des fonctionnalités pour que tout le monde travaille sur la même fonctionnalité en synchronisation, tout en n'affectant pas simultanément les autres équipes travaillant sur différentes fonctionnalités.
En même temps, vous avez à travers l'historique un ensemble de branches de publication, où vous pouvez fournir des backports, un support et des corrections de bogues pour vos clients qui, pour une raison quelconque, restent sur les versions précédentes de votre produit ou même simplement sur la dernière version publiée. Comme pour le tronc, vous ne configurez pas l'intégration continue sur les branches de publication, elles sont soigneusement intégrées après avoir réussi tous les tests de régression et autres contrôles de qualité de publication.
Si, pour une raison quelconque, deux fonctionnalités sont co-dépendantes et nécessitent des modifications l'une de l'autre, vous pouvez envisager de développer les deux sur la même branche de fonctionnalité ou d'exiger que les fonctionnalités fusionnent régulièrement des parties stables du code avec le tronc, puis actualisent les modifications de tronc pour échanger du code entre les branches du tronc. Ou si vous avez besoin d'isoler ces deux fonctionnalités des autres, vous pouvez créer une branche commune à partir de laquelle vous branchez ces branches de fonctionnalités et que vous pouvez utiliser pour échanger du code entre les fonctionnalités.
Le modèle ci-dessus n'a pas beaucoup de sens avec des équipes de moins de 50 développeurs et un système de contrôle de source sans branches clairsemées et une capacité de fusion appropriée comme CVS ou SVN, ce qui ferait de tout ce modèle un cauchemar à configurer, gérer et intégrer.