#5 : Git et ses branches
Bon. Cette fois-ci, prenons un peu de hauteur. Un aspect essentiel de l’utilisation de Git est la manière de gérer les branches. Un bon « Workflow » Git, ça permet de cadrer le développement du projet, de clarifier la méthodologie de gestion de projet et de faciliter l’utilisation des méthodes DevOps. C’est pour ça que le choix d’un workflow pertinent est très important. S’il ne les détermine pas directement, il va fortement influencer la stratégie de versionnement du projet, les phases de livraisons, la méthode de contribution, l’utilisation des outils de CI/CD, la réussite du projet, le salaire des développeurs, le réchauffement climatique et la situation géopolitique du Juras. « Tu exagères » me direz-vous, ce à quoi je répondrai peut-être.
Pourquoi utiliser des branches dans Git ?
Commençons par le commencement : pourquoi utiliser les branches dans Git ? Une branche, ça permet de porter un ensemble de modifications, cohérentes entre elles, sans perturber la version actuelle du projet. Une fois que le travail sur cette branche est stable et testé, il peut être rapatrié en une fois sur la branche principale. Grâce à ce principe, toutes les phases de développement (souvent instables) sont faites à part, dans un univers de poche (je ne me lasserai pas de cette métaphore, vous allez devoir faire avec). Du coup, lorsque ce travail est intégré à la version stable du projet, c’est de manière atomique (ou transactionnelle = on applique tout d’un coup). La stabilité du projet est ainsi garantie !
On voit donc deux types de branches émerger : les branches « permanentes » comme master (renommée récemment main dans la convention git) portant une version persistante du projet, et les branches « éphémères » qui ne vivent que le temps d’un développement, comme les branches de feature, de résolution de bug, etc. Cette différence n’a pas de réalité technique, c’est seulement une convention d’utilisation. Les branches éphémères sont supprimées une fois fusionnées dans une branche permanente, et ne doivent pas être réutilisées. Les branches principales portent les versions successives du projet en restant présentes tout au long de sa vie.
C’est quoi du coup un Workflow ?
Un workflow c’est une recommandation sur la manière d’organiser son travail, essentiellement appuyée sur l’utilisation des branches. Ça permet de cadrer le développement du logiciel en proposant une méthodologie adaptée à l’équipe. Le workflow définit quelles sont les branches « permanentes » à créer, quand, pourquoi et comment créer de nouvelles branches, et de quelle manière fusionner ces branches.
Le premier Workflow Git, et le plus connu, c’est , apparu il y a maintenant 10 ans. C’est un workflow très complet (si ce n’est le plus complet), qui résout de nombreux cas de figure : gestion d’un environnement de production et de préproduction, gestion des releases dans des branches dédiées, résolution de bugs en production ou sur d’anciennes versions du projet, maintenabilité des différentes versions du projet… Et voilà un petit aperçu du workflow :
En voilà un workflow qu’il est beau !
À première vue, pas besoin d’aller chercher plus loin. GitFlow répond à toutes les attentes et peut s’adapter à toutes les situations. La branche master représente la version stable de production, la branche develop représente la pré-prod, les branches de release permettent de gérer la correction, la QA et la résolution de bug avant livraison, etc.
Donc finalement pas besoin d’autres workflows ? Meh.
Les différents Workflow Git
Depuis la publication de Git Flow, plusieurs alternatives ont été proposées, plus ou moins basées sur le workflow d’origine. Mais si Git Flow est aussi complet, pourquoi utiliser un autre workflow ? De la même manière que cramer sa maison parce qu’on a trouvé une araignée c’est un peu overkill (bien que tout à fait sensé), Git Flow est un peu overkill pour beaucoup de projets. L’utilisation d’un workflow surdimensionné ralentira la productivité à tous les coups, sans aucun apport au projet… Quelles sont les alternatives à considérer ? En voici quelques unes !
No Flow
Parfois, il faut aller au plus simple. Une seule branche, une seule version, un seul historique. Mais un historique tout de même, et c’est bien la première utilisation de Git : le versionnement. Même s’il est très limité, ce workflow suffit pour des projets dont on souhaite simplement garder trace de l’avancée, sans gérer de livraison, de développement parallèle ou de release.
Rapidement dépassé, le « no Flow » n’est vraiment pas adapté à la gestion de projet. Tout est commité sur la même branche, donc tout est tout de suite « en production »…
Github Flow
Afin de proposer une alternative minimaliste mais fonctionnelle à GitFlow, Github a proposé son propre workflow, le (oh surprise) Github Flow.
La branche develop disparait et master reprend son rôle central dans le développement du projet. Aucun commit n’est effectué directement dans master, et la création d’une branche pour toute modification du projet permet de tester le code avant qu’il ne soit mergé dans master.
Plus accessible que GitFlow, GithubFlow est une très bonne alternative lorsqu’il s’agit de suivre un projet sans besoin de gérer un environnement de production ou une release. L’utilisation de branches de feature assure la stabilité et le travail collaboratif, sans ajouter de lourdeur au développement.
Gitlab Flow
Lorsque Github Flow n’est pas suffisant, la version proposée par Gitlab est l’option suivante à envisager. Très ressemblante, Gitlab Flow utilise la même base (master + features branches),
en ajoutant la possibilité de gérer un ou plusieurs environnements de déploiement grâce à des branches dédiées.
En cas de bug détecté directement en prodution, une branche est tirée depuis production, le bug est corrigé et la branche est ensuite à la fois fusionnée sur master ET sur production. Pour livrer une nouvelle version du projet, il suffit de merger master dans production et le tour est joué. On garde ainsi un workflow simple mais permettant cette fois de gérer la gestion d’environnements.
Bon mais du coup je prends quel Workflow Git ?
Vous savez, moi je ne crois pas qu’il y ait de bon ou de mauvais workflow…
L’important dans le choisir la solution adaptée au besoin du projet. Pas besoin d’aller chercher un GitFlow de la mort pour un POC sans mise en prod. Encore plus important, un workflow doit évoluer avec le besoin du projet. Choisir Github Flow comme base au lancement du projet c’est pragmatique. Besoin de gérer une préprod ? Passons à Gitlab Flow en ajoutant une branche preprod, qui pourra porter la version du projet à tester pour la prochaine release, et quelques temps plus tard une branche prod pour le déploiement en production.
Il faut bien garder à l’esprit qu’un workflow, ce n’est pas une loi immuable à suivre scrupuleusement… Ça s’adapte, ça se modifie, pour coller au projet et à l’équipe. Les workflows ne sont présentés ici qu’en surface (on ne parle pas de tag de versions par exemple), l’important est d’avoir les grandes lignes en tête pour choisir son worflow. On peut ensuite creuser les variations à intégrer pour se faire son workflow bien comme il faut !
