5 workflows Git et stratégie de branchement que vous pouvez utiliser pour améliorer votre processus de développement
Je n’ai pas rencontré un développeur qui a regardé un message de conflit et n’a pas tiré les mèches de ses cheveux avec frustration.
Essayer de résoudre chaque conflit de fusion est une de ces choses que tout développeur déteste. Surtout si cela vous frappe lorsque vous vous préparez à un déploiement en production !
C’est là que le fait d’avoir le bon workflow Git mis en place peut faire un monde de bien pour votre workflow de développement.
Bien sûr, avoir le bon workflow git ne résoudra pas tous vos problèmes. Mais c’est un pas dans la bonne direction. Après tout, avec chaque équipe travaillant à distance, le besoin de construire des fonctionnalités ensemble sans que votre base de code soit perturbée est critique.
La façon dont vous le mettez en place dépend du projet sur lequel vous travaillez, des calendriers de publication de votre équipe, de la taille de l’équipe, et plus encore !
Dans cet article, nous vous guiderons à travers 5 flux de travail git différents, leurs avantages, leurs inconvénients, et quand vous devriez les utiliser. Lancez-vous !
Flux de travail Git de base
Le flux de travail git le plus basique est celui où il n’y a qu’une seule branche – la branche master. Les développeurs commettent directement dans celle-ci et l’utilisent pour déployer dans l’environnement de staging et de production.
Ce flux de travail n’est généralement pas recommandé, sauf si vous travaillez sur un projet secondaire et que vous cherchez à démarrer rapidement.
Comme il n’y a qu’une seule branche, il n’y a pas vraiment de processus par ici. Cela permet de commencer à travailler avec Git sans effort. Cependant, certains inconvénients que vous devez garder à l’esprit lorsque vous utilisez ce flux de travail sont:
- Collaborer sur le code conduira à de multiples conflits.
- Les chances d’expédier des logiciels bogués en production sont plus élevées.
- Maintenir un code propre est plus difficile.
Le workflow Git Feature Branch
Le workflow Git Feature Branch devient incontournable lorsque vous avez plus d’un développeur qui travaille sur la même base de code.
Imaginez que vous avez un développeur qui travaille sur une nouvelle fonctionnalité. Et un autre développeur qui travaille sur une deuxième fonctionnalité. Maintenant, si les deux développeurs travaillent à partir de la même branche et y ajoutent des commits, cela ferait de la base de code un énorme désordre avec beaucoup de conflits.
Pour éviter cela, les deux développeurs peuvent créer deux branches distinctes à partir de la branche maître et travailler sur leurs fonctionnalités individuellement. Lorsqu’ils ont terminé leur fonctionnalité, ils peuvent alors fusionner leur branche respective à la branche maîtresse, et déployer sans avoir à attendre que la deuxième fonctionnalité soit terminée.
Le Pour de l’utilisation de ce workflow est, le workflow git feature branch vous permet de collaborer sur le code sans avoir à vous soucier des conflits de code.
Git Feature Workflow with Develop Branch
Ce workflow est l’un des plus populaires parmi les équipes de développeurs. Il est similaire au workflow Git Feature Branch avec une branche de développement qui est ajoutée en parallèle à la branche master.
Dans ce workflow, la branche master reflète toujours un état prêt pour la production. Chaque fois que l’équipe veut déployer en production, elle le fait à partir de la branche master.
La branche de développement reflète l’état avec les derniers changements de développement pour la prochaine version. Les développeurs créent des branches à partir de la branche de développement et travaillent sur de nouvelles fonctionnalités. Une fois que la fonctionnalité est prête, elle est testée, fusionnée avec la branche develop, testée avec le code de la branche develop au cas où il y aurait eu une fusion préalable, puis fusionnée avec master.
L’avantage de ce flux de travail est qu’il permet aux équipes de fusionner systématiquement les nouvelles fonctionnalités, de les tester en staging et de les déployer en production. Bien que la maintenance du code soit plus facile, elle peut devenir un peu fastidieuse pour certaines équipes, car elles peuvent avoir l’impression de passer par un processus fastidieux.
Le flux de travail gitflow
Le flux de travail gitflow est très similaire au flux de travail précédent dont nous avons discuté, combiné avec deux autres branches – la branche release et la branche hot-fix.
La branche hot-fix
La branche hot-fix est la seule branche qui est créée à partir de la branche maître et directement fusionnée à la branche maître au lieu de la branche de développement. Elle est utilisée uniquement lorsque vous devez rapidement corriger un problème de production. Un avantage de cette branche est, qu’elle vous permet de déployer rapidement un problème de production sans perturber le flux de travail des autres ou sans avoir à attendre le prochain cycle de publication.
Une fois que le correctif est fusionné dans la branche master et déployé, il doit être fusionné à la fois dans la branche development et dans la branche release actuelle. Ceci est fait pour s’assurer que toute personne qui bifurque de develop pour créer une nouvelle branche de fonctionnalités dispose du dernier code.
La branche release
La branche release est bifurquée de la branche develop après que cette dernière ait fusionné avec succès toutes les fonctionnalités prévues pour la release.
Aucun code lié aux nouvelles fonctionnalités n’est ajouté dans la branche release. Seul le code qui se rapporte à la version est ajouté à la branche release. Par exemple, la documentation, les corrections de bogues et les autres tâches liées à cette version sont ajoutées à cette branche.
Une fois que cette branche est fusionnée avec master et déployée en production, elle est également fusionnée à nouveau dans la branche development, de sorte que lorsqu’une nouvelle fonctionnalité est bifurquée de develop, elle dispose du dernier code.
Ce flux de travail a été publié et popularisé pour la première fois par Vincent Driessen et depuis lors, il a été largement utilisé par les organisations qui ont un cycle de publication planifié.
Comme le git-flow est un wrapper autour de Git, vous pouvez installer git-flow dans votre dépôt actuel. C’est un processus simple et il ne change rien dans votre dépôt autre que la création de branches pour vous.
Pour installer sur une machine Mac, exécutez brew install git-flow dans votre terminal.
Pour installer sur une machine Windows, vous devrez télécharger et installer le git-flow. Une fois l’installation terminée, exécutez la commande Git suivante git flow init pour l’utiliser dans votre projet.
Le flux de travail Fork de Git
Le flux de travail Fork est populaire parmi les équipes qui utilisent des logiciels open-source.
Le flux ressemble généralement à ceci:
- Le développeur fork le dépôt officiel du logiciel open-source. Une copie de ce dépôt est créée dans son compte.
- Le développeur clone ensuite le dépôt de son compte sur son système local.
- Un chemin distant pour le dépôt officiel est ajouté au dépôt cloné sur le système local.
- Le développeur crée une nouvelle branche de fonctionnalité est créée dans son système local, apporte des modifications et les commite.
- Ces modifications ainsi que la branche sont poussées vers la copie du référentiel du développeur sur son compte.
- Une demande de pull de la branche est ouverte vers le dépôt officiel.
- Le gestionnaire du dépôt officiel vérifie les modifications et approuve les modifications pour qu’elles soient fusionnées dans le dépôt officiel.
Automatiser vos flux de travail Git et votre stratégie de branchement pour une meilleure productivité
L’une des choses avec lesquelles les développeurs doivent constamment jongler est la mise à jour de leur outil de gestion de projet pour que leurs coéquipiers soient à jour. C’est pourquoi, chez Zepel, nos développeurs automatisent leur flux de travail, afin qu’ils puissent consacrer plus de temps à la construction du logiciel.
Voici comment nous automatisons notre flux de travail git pour que tout le monde reste synchronisé :
Bien que Zepel s’intègre profondément à GitHub, Bitbucket, et GitLab, nous utilisons GitHub en interne. Ainsi, une fois que nous avons intégré GitHub à Zepel, notre équipe de développement met en place l’automatisation du flux de travail git dans Zepel. Voici à quoi cela ressemble aujourd’hui :
Au fur et à mesure que les développeurs continuent de progresser, notre équipe reçoit automatiquement une notification Slack et leurs changements sont enregistrés dans la user story.
Votre propre workflow et stratégie de branchement Git !
Les workflows git que j’ai présentés dans cet article sont des exemples de certains des workflows populaires et qui fonctionnent le mieux pour l’équipe de développement. Certaines équipes créent une branche pour Staging et cela fonctionne parfaitement pour elles.
Si vous utilisez d’autres workflows qui fonctionnent bien pour vous, tweetez-nous @getzepel. Nous aimerions les présenter !
Articles utiles
Vikash KoushikThe Zepel Blog 
Ranjali RoyThe Zepel Blog iv
Ranjali RoyThe Zepel Blog 
.