Qu’est-ce que GitFlow?
GitFlow est un modèle de branchement pour Git, créé par Vincent Driessen. Il a attiré beaucoup d’attention car il est très bien adapté à la collaboration et à la mise à l’échelle de l’équipe de développement.
Principaux avantages
Développement parallèle
L’une des grandes choses de GitFlow est qu’il rend le développement parallèle très facile, en isolant le nouveau développement du travail fini. Le nouveau développement (comme les fonctionnalités et les corrections de bogues non urgentes) se fait dans des branches de fonctionnalités, et n’est fusionné de nouveau dans le corps principal du code que lorsque le ou les développeurs sont heureux que le code soit prêt à être publié.
Bien que les interruptions soient un BadThing(tm), si on vous demande de passer d’une tâche à une autre, tout ce que vous avez à faire est de commiter vos changements, puis de créer une nouvelle branche de fonctionnalités pour votre nouvelle tâche. Lorsque cette tâche est terminée, il suffit de vérifier votre branche de fonctionnalité d’origine et vous pouvez continuer là où vous vous êtes arrêté.
Collaboration
Les branches de fonctionnalité facilitent également la collaboration de deux développeurs ou plus sur la même fonctionnalité, car chaque branche de fonctionnalité est un bac à sable où les seuls changements sont ceux nécessaires pour faire fonctionner la nouvelle fonctionnalité. Cela permet de voir et de suivre très facilement ce que fait chaque collaborateur.
Release Staging Area
A mesure que le nouveau développement est terminé, il est fusionné de nouveau dans la branche develop, qui est une zone de transit pour toutes les fonctionnalités terminées qui n’ont pas encore été publiées. Ainsi, lorsque la prochaine version est branchée à partir de develop, elle contiendra automatiquement toutes les nouvelles choses qui ont été terminées.
Support des corrections d’urgence
GitFlow supporte les branches hotfix – des branches faites à partir d’une version étiquetée. Vous pouvez les utiliser pour effectuer une modification d’urgence, en sachant que le hotfix ne contiendra que votre correctif d’urgence. Il n’y a aucun risque que vous fusionniez accidentellement dans un nouveau développement en même temps.
Comment ça marche
Les nouveaux développements (nouvelles fonctionnalités, corrections de bogues non urgentes) sont construits dans des branches de fonctionnalités :
Les branches de fonctionnalités sont branchées à partir de la branche de développement, et les fonctionnalités et corrections terminées sont fusionnées à nouveau dans la branche de développement lorsqu’elles sont prêtes à être publiées :
Quand il est temps de faire une version, une branche de version est créée à partir de la branche de développement :
Le code de la branche release est déployé sur un environnement de test adapté, testé, et les problèmes éventuels sont corrigés directement dans la branche release. Ce cycle déployer -> tester -> corriger -> redéployer -> retester se poursuit jusqu’à ce que vous soyez satisfait que la version soit suffisamment bonne pour la diffuser aux clients.
Quand la version est terminée, la branche release est fusionnée dans master et dans develop aussi, pour s’assurer que les changements effectués dans la branche release ne sont pas accidentellement perdus par un nouveau développement.
La branche master suit uniquement le code publié. Les seuls commits vers master sont des fusions à partir des branches release et des branches hotfix.
Les branches hotfix sont utilisées pour créer des correctifs d’urgence :
Elles sont branchées directement à partir d’une version étiquetée dans la branche master, et lorsqu’elles sont terminées, elles sont fusionnées à nouveau à la fois dans master et dans develop pour s’assurer que le correctif n’est pas accidentellement perdu lors de la prochaine version régulière.
.
0 commentaire