Bien gerer son (work)flow avec git
#git #githubRetrouvez l’article sur le blog de Code Insider:
https://blog.codeinsider.fr/gerer-son-worklfow-avec-git/
Mise à part le fait d’être un hébergement meublé touristique ou un morceaux de viande de boeuf situé dans la cuisse, Git est un outil de versionning décentralisé et libre de droit créé par Linus torvald, l’auteur du tout petit noyau de système d’exploitation répondant au doux nom de Linux. Utilisé par plus de douze millions de personnes à travers le monde, Git est le logiciel de gestion de version le plus populaire sur la Terre. En 2017, Microsoft quitte le bon vieux Apache Subversion, aka SVN pour migrer le code de Windows vers Git. Microsoft renforce son lien avec Git en rachetant, en juin 2018, le site Github (à ne pas confondre avec le site: http://guthib.com/) pour la modique somme de 7.5 Milliard de dollars.
Mais comment bien gérer son système de branche ? Voici une sélection de différente manière de gérer (plus ou moins bien) ses branches. Il est conseillée de connaître le fonctionnement de Git avant de lire cet article.
Pour les néophytes, la documentation officiel est bien écrite : https://git-scm.com/book/fr/v1/Les-bases-de-Git
NoFlow aka “Utiliser Git comme SVN”:
Cette méthode est la plus simple puisqu’il suffit de publier son travail sur la seul et unique branche existante par défaut : la branche master.
Cette méthode est principalement utilisée par les développeurs solo afin de versionner leur code.
[image : http://blog.programster.org/git-workflows]
L’image ci-dessous est la représentation réaliste d’un chef de projet ne connaissant pas la puissance de Git :
GitFlow aka “La machine de guerre” :
Le principe de GitFlow est de fonctionner sur deux branches principales : la branche de développement (develop) et la branche de production (master).
Chaque nouvelle modification du projet doit être faite via des sous-branches, aux nombres de trois, qui sont ensuite fusionnées aux branches principales :
Pour ajouter des nouvelles fonctionnalités, il faut créer une branche “feature”, elle sera ajoutée à la branche develop ou à une branche de release.
Si on souhaite fixer une erreur sur la branche master, il faut créer une nouvelle branche "hotfix”. Cette dernière sera fusionnée sur les deux branches principales.
Dès que l’on souhaite créer une release, on créé une branche “release” qui sert de branche principale aux nouvelles fonctionnalités de cette dernière. Lorsque la release arrive en production, les commits de cette branche sont rajoutés à la branche master ainsi qu’à la branche develop pour permettre de continuer aisément le développement de nos fonctionnalités sans problème majeur lors de futurs fusions de branches.
La convention de nommage des sous-branches consiste à les nommer selon leur fonctionnalité première (“feature”, “hotfix”, “release”) suivis du numéro du ticket, ou son nom, ou sa fonctionnalité, etc. (example: “feature-1”)
Il existe un outil permettant d’utiliser ce workflow plus facilement : https://github.com/nvie/gitflow
OneFlow aka “Git Flow sur une branche principale” :
Le principe de fonctionnement de Oneflow est une amélioration de Git Flow, le changement majeur est qu’il n’existe pas de branche develop.
Le principal avantage est d’avoir un historique git plus propre tout en conservant ceux de Git Flow.
[image : https://commons.wikimedia.org/wiki/File:OneFlow_Example.png]
Gitlab Flow aka “Ma Pre-production contient precisement ces commits” :
A l’inverse de tous les autres workflow, GitLab Flow a sa propre branche de production dont le dernier commit sur cette fameuse branche est la version actuelle du service, GitFlow est lui aussi est basé sur trois branches principales :
-> La branche master, qui représente l’environnement de développement
-> La branche staging, qui représente le contenu de la version de pré-production
-> La branche production, qui est la version publie sur les serveurs de production
L’avantage d’utiliser ce workflow est qu’il est facilement possible de savoir les commits utilisés dans chaque environnement.
[image : http://blog.programster.org/git-workflows]
GitHub Flow aka ”Qui peut mettre en prod mon code ?” :
Le site Github implémente le système de Pull Request en 2008. Cette ajout fut une révolution pour les projet open-source, permettant à un utilisateur de pouvoir fusionner son code dans une autre branche à la suite d’une validation manuelle d’un ou plusieurs personnes.
Github Flow place au coeur de son workflow le Pull Request. Le développeur crée une nouvelle branche sur laquelle il va faire ses modifications. Après avoir fini son développement, le développeur crée une pull request. Tant que la demande n’as pas été validée par l’équipe, le développeur peut modifier son code. Si l’équipe valide la modification, cette dernière est fusionnée au code principal. La branche principal du projet est donc fonctionnel et livrable en production.
Cette méthode est principalement utilisée sur des projets avec de petites équipes.
[image : https://hackernoon.com/15-tips-to-enhance-your-github-flow-6af7ceb0d8a3]
Trunk Based Development aka “Tout sur master”:
La différence majeur, entre le trunk-based et Github Flow, est que la branche master n’est pas considérée comme utilisable en production. Toutes les fonctionnalités sont ajoutées à la branche principale, et seuls les commits de corrections sont ajoutés à la branche de release (après avoir été ajoutés au trunk).
Cette pratique permet d’éviter d’avoir des conflits de merge et de permettre d’avoir un programme toujours compilable et fonctionnel.
[image : https://paulhammant.com/2013/04/05/what-is-trunk-based-development/]
Conclusion
Pour conclure, hormis la première méthode, toutes sont conseillées pour un travail avec plusieurs collaborateurs, chacune étant adaptée pour un besoin. Il faut donc prendre le temps de les tester pour trouver la plus convenable pour son projet. Pour ma part, j’utilise “No Flow” sur mes projets personnels, “GitHub Flow” pour les projets en petite équipe et “GitFlow” en entreprise, même si je sais pertinemment que l’on a pas besoin d’un workflow aussi important, il est plus facile de faire de l'intégration continue dessus.
Un autre point intéressant qui fera l’objet d’un article dans un futur proche : la convention de nommage de ses commits et son importance lors de son traçage dans l’historique du projet.