Dans le monde actuel du développement de logiciels, la vitesse et l’agilité sont cruciales lorsqu’il s’agit de développer et de sortir un logiciel. Cependant, lorsqu’une grande équipe de développeurs travaille simultanément, les branches et les fusions de code peuvent rapidement devenir désordonnées. 

C’est pourquoi les équipes doivent mettre en place un processus permettant d’implémenter plusieurs changements à la fois. C’est la raison pour laquelle la mise en place d’une stratégie de branches efficace devient une priorité pour ces équipes.

Qu’est-ce qu’une stratégie de branches ?

Les branches sont utilisées essentiellement comme un moyen pour les équipes de développer des fonctionnalités en leur donnant un espace de travail séparé pour leur code. Ces branches sont généralement rattachées à la branche principale une fois le travail terminé. De cette manière, les fonctionnalités, les bugs et les corrections de bugs sont séparés les uns des autres, ce qui permet de corriger les erreurs plus facilement.

Cela signifie que les branches protègent la chaîne principale du code et que les modifications apportées à une branche donnée n’affectent pas les autres développeurs.

Une telle stratégie est nécessaire car elle permet de maintenir les référentiels organisés afin d’éviter toute erreur dans une application et l’enfer de la fusion, redouté lorsque plusieurs développeurs travaillent simultanément et ajoutent toutes leurs modifications en même temps. 

De tels conflits de fusion finiraient par décourager l’envoi rapide de code et par empêcher la création et le maintien d’un processus DevOps efficace, car l’objectif principal de DevOps est de créer un flux de travail rapide qui permette la publication de petits lots de code.

Ainsi, l’adhésion à une stratégie de branches permet de résoudre ce problème afin que les développeurs puissent travailler ensemble sans se marcher sur les pieds. En d’autres termes, cette stratégie permet aux équipes de travailler en parallèle afin d’obtenir des versions plus rapides et de réduire les conflits en créant un processus clair pour les modifications apportées au code source.

Lorsque nous parlons de branches, nous faisons référence à des lignes de code indépendantes qui partent de la branche principale, permettant aux développeurs de travailler indépendamment avant de fusionner leurs modifications avec le code source.

Dans cet article, nous décrirons quelques-unes des stratégies de branches utilisées par les équipes pour organiser leur flux de travail et nous examinerons leurs avantages et leurs inconvénients, ainsi que la stratégie que vous devriez choisir en fonction de vos besoins, de vos objectifs et des capacités de votre équipe.

Pourquoi avez-vous besoin d’une stratégie de branches ?

Comme indiqué ci-dessus, il est nécessaire d’avoir une stratégie de branches pour éviter les conflits lors de la fusion et pour faciliter l’intégration des modifications au tronc principal.

Git Branching

Les branches ne sont pas réservées à Git. Cependant, dans cet article, nous nous concentrons sur Git en raison des nombreux avantages que ce modèle de branches offre.

Par conséquent, avant de nous plonger dans les différentes stratégies de branches existantes, y compris les stratégies de branches de Git, nous allons examiner comment Git gère les branches et pourquoi il se distingue des autres outils de contrôle de version.

En termes simples, Git et les autres outils de contrôle de version permettent aux développeurs de suivre, de gérer et d’organiser leur code.

Les branches Git permettent aux développeurs de s’écarter de la branche principale en créant des branches distinctes pour isoler les modifications du code. La branche par défaut de Git est la branche principale. 

Le principal avantage d’une branche Git est qu’elle est « légère », ce qui signifie que les données sont constituées d’une série de snapshots. Ainsi, à chaque validation, Git prend une photo de vos fichiers à ce moment-là et stocke une référence à ce snapshot. Cela signifie que ces branches ne sont pas de simples copies du système de fichiers, mais simplement un pointeur vers le dernier dépôt.

En revanche, d’autres outils de contrôle de versions stockent les informations sous la forme d’une liste de modifications basées sur des fichiers, ce qui peut ralentir le processus et occuper beaucoup d’espace. 

Dans Git, une branche est essentiellement une référence ou un pointeur vers le dernier changement dans un contexte donné ; ce n’est pas un conteneur pour les changements. Au fur et à mesure que vous créez de nouvelles modifications dans la nouvelle branche, Git crée de nouveaux pointeurs pour suivre ces changements. Les branches Git peuvent donc être considérées comme un pointeur vers un instantané de vos modifications. 

Les images ci-dessous illustrent ce concept : l’image du haut montre la branche main et un pointeur pointant vers le dernier dépôt, et l’image juste en dessous montre ce qui se passe lorsque vous créez une nouvelle branche appelée  » dev « : un nouveau pointeur pointe désormais vers le dernier dépôt.

En résumé, le modèle de branches de Git est plus léger que celui des autres systèmes de contrôle de version ; c’est pourquoi il est si facile et peu coûteux de créer des branches dans Git, car il n’est pas nécessaire de copier l’ensemble du code dans la branche, ce qui crée un grand nombre de fichiers en double, contrairement à d’autres outils de contrôle de version.

Quelles sont les stratégies de branches les plus fréquentes avec Git ?

GitFlow

Considéré comme assez compliqué et avancé pour de nombreux projets actuels, GitFlow permet un développement parallèle dans lequel les développeurs peuvent travailler sur des fonctionnalités séparément de la branche principale, grâce à une branche de fonctionnalités créée à partir de celle-ci.

Ensuite, lorsque les modifications sont terminées, le développeur les fusionne avec la branche principale pour la publication.

Cette stratégie de ramification se compose des branches suivantes :

• La branche principale 
• Le développement
• La fonctionnalité : pour développer de nouvelles fonctionnalités à partir de la branche de développement. 
• La release : permet de préparer une nouvelle release production. Elle est généralement dérivée de la branche de développement et doit être fusionnée à la fois à la branche de développement et à la branche principale.
• Hotfix : aide également à préparer une release. Cependant, contrairement aux branches release, les branches hotfix sont issues d’un bug qui a été découvert et qui doit être résolu. Elles permettent aux développeurs de continuer à travailler sur leurs propres modifications sur la branche de développement pendant que le bug est en train d’être corrigé.

Les branches principale et de développement sont considérées comme les branches principales, avec une durée de vie infinie, tandis que les autres sont des branches de soutien destinées à faciliter le développement parallèle entre les développeurs, généralement de courte durée.

Les avantages et les contraintes de GitFlow

L’avantage le plus évident de ce modèle est qu’il permet un développement parallèle afin de protéger le code de production, de sorte que la branche principale reste stable pour la publication pendant que les développeurs travaillent sur des branches séparées.

En outre, les différents types de branches permettent aux développeurs d’organiser plus facilement leur travail. Cette stratégie contient des branches distinctes et directes pour des objectifs spécifiques, bien qu’elle puisse devenir compliquée pour de nombreux cas d’utilisation. 

Elle est également idéale pour gérer plusieurs versions d’un même code de production.

Cependant, au fur et à mesure que des branches sont ajoutées, elles peuvent devenir difficiles à gérer car les développeurs fusionnent leurs modifications de la branche de développement à la branche principale. Les développeurs devront d’abord créer la branche de publication, puis s’assurer que tout travail final est également fusionné dans la branche de développement, avant de fusionner cette branche de publication dans la branche principale.

Si les modifications sont testées et que le test échoue, il devient de plus en plus difficile de déterminer où se situe exactement le problème, car les développeurs sont perdus dans une masse de modifications.

En effet, la complexité de GitFlow pourrait ralentir le processus de développement et le cycle de publication. En ce sens, GitFlow n’est pas une approche efficace pour les équipes qui souhaitent mettre en œuvre l’intégration continue et le déploiement continu. 

Dans ce cas, un flux de travail beaucoup plus simple, tel que GitHub Flow, est recommandé.

GitHub Flow

GitHub Flow est une alternative plus simple à GitFlow, idéale pour les petites équipes qui n’ont pas besoin de gérer plusieurs versions.

Contrairement à GitFlow, ce modèle n’a pas de branches de release. Vous commencez avec la branche principale, puis les développeurs créent des branches de fonctionnalités qui découlent directement de la branche principale, pour isoler leur travail qui est ensuite fusionné dans la branche principale. La branche de fonctionnalité est ensuite supprimée.

L’idée principale de ce modèle est de maintenir le code principal dans un état constant de déploiement et donc de soutenir les processus d’intégration continue et de déploiement continu.

Les avantages et les inconvénients de GitHub Flow

Github Flow se concentre sur les principes de la méthode Agile. Il s’agit donc d’une stratégie de branches rapide et rationalisée, avec des cycles de production courts et des releases fréquentes. 

Cette stratégie prévoit également des boucles de rétroaction rapides afin que les équipes puissent rapidement identifier les problèmes et les résoudre.

Comme il n’y a pas de branche de développement, vous testez et automatisez les changements sur une seule branche, ce qui permet un déploiement rapide et continu.

Cette stratégie est particulièrement adaptée aux petites équipes et aux applications web et elle est idéale lorsque vous devez maintenir une seule version de production.

Cette stratégie n’est donc pas adaptée à la gestion de plusieurs versions du code.

En outre, l’absence de branches de développement rend cette stratégie plus vulnérable aux bugs et peut donc conduire à un code de production instable, particulièrement si les branches ne sont pas correctement testées avant d’être fusionnées avec la branche de release principale et si les corrections de bugs sont effectuées sur cette branche. Par conséquent, la branche principale peut s’encombrer plus facilement puisqu’elle sert à la fois de branche de production et de branche de développement.

Un autre inconvénient est que ce modèle est plus adapté aux petites équipes et donc, lorsque les équipes grandissent, des conflits de fusion peuvent se produire car tout le monde fusionne sur la même branche et il y a un manque de transparence. Ceci signifie que les développeurs ne peuvent pas voir sur quoi les autres développeurs travaillent.

GitLab Flow

GitLab Flow est une alternative plus simple à GitFlow qui combine le développement axé sur les fonctionnalités et les branches de fonctionnalités avec le repérage des incidents.

Avec GitFlow, les développeurs créent une branche de développement et en font la branche par défaut, tandis que GitLab Flow travaille immédiatement avec la branche principale.

GitLab Flow est idéal si vous souhaitez maintenir plusieurs environnements et si vous préférez disposer d’un environnement d’essai distinct de l’environnement de production. Ensuite, lorsque la branche principale est prête à être déployée, vous pouvez la fusionner avec la branche de production et la publier.

Cette stratégie offre donc une réelle isolation entre les environnements, ce qui permet aux développeurs de maintenir plusieurs versions du logiciel dans des environnements différents.

Alors que GitHub Flow suppose que vous pouvez déployer en production chaque fois que vous fusionnez une branche de fonctionnalités avec la branche principale, GitLab Flow cherche à résoudre ce problème en permettant au code de passer par des environnements internes avant d’atteindre la production, comme le montre l’image ci-dessous.

Cette méthode convient donc aux situations où vous ne contrôlez pas le moment de la release, comme dans le cas d’une application iOS qui doit d’abord être validée par l’App Store ou lorsque vous avez des fenêtres de déploiement spécifiques.

Développement basé sur le tronc

Le développement basé sur le tronc est une stratégie de branches qui ne nécessite en fait aucune branche. Les développeurs intègrent leurs modifications dans un tronc partagé au moins une fois par jour. Ce tronc commun doit être prêt à être publié à tout moment.

L’idée principale derrière cette stratégie est que les développeurs fassent des changements plus petits et plus fréquemment, et donc l’objectif est de limiter les branches de longue durée et d’éviter les conflits de fusion puisque tous les développeurs travaillent sur la même branche. En d’autres termes, les développeurs s’engagent directement dans le tronc sans utiliser de branches.

Par conséquent, le développement basé sur le tronc est un élément clé de l’intégration continue (CI) et du déploiement continu (CD), car les modifications sont apportées plus fréquemment au tronc, souvent plusieurs fois par jour (CI), ce qui permet de publier les fonctionnalités beaucoup plus rapidement (CD).

Cette stratégie est souvent combinée avec les feature flags. Comme le tronc est toujours prêt à être publié, les feature flags permettent de découpler le déploiement de la publication. Ainsi, toute modification qui n’est pas prête peut être enveloppée dans un feature flag et gardée cachée, tandis que les fonctionnalités complètes peuvent être mises à disposition des utilisateurs finaux sans délai.

Les avantages et les inconvénients du développement axé sur le tronc

Comme nous l’avons vu, le développement axé sur le tronc ouvre la voie à l’intégration continue car le tronc est constamment mis à jour.

Il améliore également la collaboration, car les développeurs ont une meilleure visibilité sur les modifications apportées par les autres développeurs, étant donné que les modifications sont effectuées directement sur le tronc, sans qu’il soit nécessaire de créer des branches. Cette méthode est différente des autres méthodes de branches où chaque développeur travaille indépendamment dans sa propre branche et où les modifications apportées à cette branche ne sont visibles qu’après avoir été fusionnées avec la branche principale.

Comme le développement axé sur le tronc ne nécessite pas de branches, cela élimine le stress des branches de longue durée et donc les conflits de fusion ou le fameux « enfer de la fusion », car les développeurs apportent de petites modifications beaucoup plus souvent. Cela facilite également la résolution des conflits éventuels.

Enfin, cette stratégie permet des releases plus rapides car le tronc commun est maintenu dans un état constant de release avec un flux continu de travail intégré dans le tronc, ce qui se traduit par une version plus stable.

Cependant, cette stratégie convient aux développeurs plus expérimentés, car elle offre une grande autonomie que les développeurs inexpérimentés pourraient trouver décourageante puisqu’ils interagissent directement avec le tronc commun. Par conséquent, pour une équipe plus junior dont vous devez surveiller le travail de près, vous pouvez opter pour une stratégie de branches Git.

Comment choisir la meilleure stratégie de branches pour votre équipe ?

Lorsque l’on débute, il est préférable d’aller au plus simple et donc, dans un premier temps, le développement GitHub Flow ou axé sur le tronc peut s’avérer le plus adapté. Ils sont également idéaux pour les petites équipes qui n’ont besoin que d’une seule version d’un projet à maintenir. 

GitFlow est idéal pour les projets open-source qui nécessitent un contrôle d’accès strict aux modifications. C’est d’autant plus important que les projets open-source permettent à tout un chacun de contribuer et qu’avec GitFlow, vous pouvez vérifier ce qui est introduit dans le code source.

Cependant, GitFlow, comme mentionné précédemment, n’est pas adapté à la mise en œuvre d’un environnement DevOps. Dans ce cas, les autres stratégies discutées conviennent mieux à un processus DevOps agile et au soutien de votre pipeline de CI-CD.

Le tableau suivant résume les stratégies discutées dans cet article et indique quelle stratégie est appropriée dans quel contexte :

Type de produit et méthode de diffusion	Taille de l’équipe	Maturité de la collaboration	Stratégie de branches principale applicable
Tout	Petites équipes	Haute	Développement basé sur le tronc
Produits permettant un déploiement et une mise à jour continus, tels que les produits SaaS.	Moyenne	Moyenne	GitHub-Flow et développement basé sur le tronc
Produits avec une fenêtre de release définie et une cadence de publication périodique, tels que les applications iOS.	Moyenne	Moyenne	Git-Flow et GitLab-Flow avec branche de release
Produits exigeants en termes de qualité et supportant un déploiement et des releases en continu, tels que les plateformes produits de base.	Moyenne	Moyenne	GitLab-Flow
Produits exigeants en termes de qualité et ayant un long cycle de maintenance pour les versions publiées, tels que les plateformes produits de base 2B.	Grande	Moyenne	Git-Flow

En résumé, la stratégie parfaite n’existe pas. La stratégie que vous choisirez dépendra de votre équipe ainsi que de la nature et de la complexité de votre projet et devra donc être évaluée au cas par cas.

Il est également possible de commencer par une stratégie et de l’adapter au fil du temps en fonction de vos besoins. Il va sans dire que, quelle que soit la stratégie choisie, elle doit viser à accroître la productivité de votre équipe en lui donnant une stratégie claire et cohérente pour organiser son travail.