Stratégies de branches
Last updated
Last updated
Bibliographie:
Git est essentiel dans un projet pour gérer efficacement les versions du code et faciliter la collaboration entre les développeurs.
Il permet de suivre les modifications, de revenir à des versions précédentes et d'intégrer du code sans conflits.
Choisir la bonne stratégie de branches est crucial pour structurer le développement et éviter le chaos dans la gestion des fonctionnalités.
Une bonne stratégie assure un flux de travail fluide, réduit les risques d'erreurs et permet des livraisons plus organisées.
Git est le système de contrôle de version le plus utilisé aujourd'hui. Un Workflow Git est une recette ou une recommandation sur la façon d'utiliser Git pour accomplir un travail de manière cohérente et productive.
Les Workflows Git encouragent les développeurs et les équipes DevOps à utiliser Git de manière efficace et cohérente. Git offre une grande flexibilité dans la manière dont les utilisateurs gèrent les changements.
Compte tenu de l'accent mis par Git sur la flexibilité, il n'existe pas de processus standardisé sur la façon d'interagir avec Git.
Lorsque l'on travaille avec une équipe sur un projet géré par Git, il est important de s'assurer que tous les membres de l'équipe sont d'accord sur la façon dont le flux de changements sera appliqué.
Pour s'assurer que l'équipe est sur la même longueur d'onde (pratiques partagées), un workflow Git convenu doit être développé ou sélectionné. Il existe plusieurs Workflow Git publiés qui peuvent convenir à votre équipe.
Le Feature Branching est une extension logique du Workflow centralisé. L'idée de base du workflow Feature Branch est que tous les développements de fonctionnalités doivent avoir lieu dans une branche dédiée plutôt que dans la branche principale.
Cette encapsulation permet à plusieurs développeurs de travailler sur une sur une fonctionnalité particulière sans perturber la base de code principale.
Gitflow est un Workflow Git hérité qui était à l'origine une stratégie innovante pour la gestion des branches Git.
Gitflow peut être utilisé pour les projets qui ont un cycle de publication programmé et pour la meilleure pratique DevOps de livraison continue. Ce workflow n'ajoute pas de nouveaux concepts ou commandes au-delà de ce qui est requis pour le workflow Feature Branch. En revanche, il attribue des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir. En plus des branches de fonctionnalités, il utilise des branches individuelles pour la préparation, la maintenance et l'enregistrement des versions. Bien entendu, vous bénéficiez également de tous les avantages du Feature Branch Workflow : demandes d'extraction, expériences isolées et collaboration plus efficace.
Gitflow a plus de branches à durée de vie longue et des commits plus importants que le développement trunk-based.
Dans ce modèle, les développeurs créent une branche de fonctionnalité et retardent sa fusion avec la branche principale jusqu'à ce que la fonctionnalité soit terminée. Ces branches de fonctionnalités à longue durée de vie nécessitent une plus grande collaboration pour les fusionner car elles présentent un risque plus élevé de s'écarter de la branche principale et d'introduire des mises à jour conflictuelles.
Gitflow dispose également de branches primaires distinctes pour le développement, les correctifs, les fonctionnalités et les versions. Il existe différentes stratégies pour fusionner les commits entre ces branches. Comme il y a plus de branches à jongler et à gérer, il y a souvent plus de complexité qui nécessite des sessions de planification et de révision supplémentaires de la part de l'équipe.
Le développement trunk-based est beaucoup plus simplifié puisqu'il se concentre sur la branche principale en tant que source de corrections et de versions.
Gitflow a plus de branches à durée de vie longue et des commits
Le flux de travail Forking est fondamentalement différent des autres flux de travail Git populaires. Au lieu d'utiliser un seul dépôt côté serveur pour agir comme la base de code « centrale », il donne à chaque développeur son propre dépôt côté serveur.
Cela signifie que chaque contributeur ne dispose pas d'un, mais de deux dépôts Git : un dépôt local privé et un dépôt public côté serveur. Le processus de bifurcation est le plus souvent utilisé dans les projets open source publics.