II - Git: Gitflow

I- Introduction:
Gitflow est un wrapper pour git qui est extrêmement utile pour le Devops.
Il permet de définir un modèle strict de structuration des branches lors de la gestion de grands projets.
Il n'ajoute pas grand choses au fonctionnement initial de Git si ce n'est le fait de pouvoir définir des branches avec des rôles spécifiques pour la gestion du développement local, des déploiement et des diverses maintenances liées à notre projet.
II- Fonctionnement:
Gitflow possède un cli permettant de faire des commandes basiques que vous verrez peuvent bien se faire en utilisant juste Git, mais pour des raisons de facilité nous utiliserons gitflow pour éviter de se tromper.
Vous pouvez l'installer en vous rendant sur le lien suivant.
Pour commencer un projet avec gitflow il vous suffit de faire un coup de git-flow init
. Cette commande a le même fonctionnement que git init
sauf qu'elle rajoute deux branches aux projets plutôt qu'une master et develop et crée l'organisation des branches de features, release, hotfix, ... dont on parlera dans la suite de cet article.
La commande git flow init
sans aucune modification crée ceci
Cette commande peut être faite sans avoir besoin de git-flow en faisant:
git branch develop
git push -u origin develop
Au lieu de n'avoir que la branche master pour gérer l'entièreté du projet, gitflow crée la branche develop qui s'occupera de toutes les features qui seront développée et au debut cette branche là est directement forkée à partir de la branche master. La branche master ne servira qu'à stocker les informations sur les releases.
L'arborescence du git ressemblera à ceci
Maintenant que nous savons comment GitFlow crée le repo git sur le projet, nous allons essayer de démystifier les branches features, hotfix et release.
Features:
Les branches features sont forkées à partir de la dernière version de develop.
Elles se basent sur le fait que chaque fonctionnalité du projet doit résider sur une branche propre à elle et ne doit pas intéragir avec la branche master mais directement mergée sur develop à la fin son développement.
Pour créer une nouvelle feature la commande git-flow correspondante est:
git flow feature start feature_name
Avec git:
git checkout develop
git checkout -b feature_name
Ces branches comme toutes les autres d'ailleurs peuvent être rendues publiques pour des fins de collaboration. C'est à ça que sert la commande publish de git flow.
Pour publier notre branche feature_name, la commande correspondante est git flow feature publish feature_name
.
Une fois le developpement de la feature terminée, elle sera mergée sur develop souvenez-vous rien ne doit toucher à la branche master venant des features.
Avec git flow:
git flow feature finish feature_name
Avec git:
git checkout develop
git merge feature_name
Releases:
Une release peut être vue comme une autorisation de publier. Elles sont nées lorsque la branche develop atteint un certain niveau de maturité et que l'on ait besoin de publier et partir de cette nouvelle base.
Une fois qu'une release est initiée il ne faut rajouter aucune feature dans celle-ci, on ne peut faire que des opérations de modifications mineures comme des résolutions de bugs par exemple.
Les releases sont forkées de develop pour aller se brancher sur master et representer de nouvelles versions du projet.
Il est important après une release de remerger le projet sur develop vu que des modifications ont peut-être pû être apportées entre l'initiation et la fin.
Pour créer une release avec git flow:
git flow release start version
Je vous invite à vous rendre sur ce lien pour comprendre comment les versions sont faites.
Avec git:
git checkout develop
git checkout -b release/version
On peut de la même manière qu'avec les features publier les release pour des fins de collaboration.
On peut se mettre sur la branche release publiée par un autre membre de l'équipe ou soi-même avec la commande git flow release track version
.
Une fois que tout est prêt pour terminer la release, on la met sur master, on supprime la branche intermédiaire créée, et on n'oublie surtout pas de remerger sur develop.
Avec git flow:
git flow release finish version
Avec git:
git checkout master
git merge release/version
git checkout develop
git merge release/version
git branch -D release/version
Hotfixes
Les hotfixes ou branches de maintenance servent à faire des résolutions de bugs pour des versions dejà publiées sur master. Ce sont les seules branches à pouvoir directement récupérer le code se trouvant sur master et il faut noter qu'après avoir fini la maintenance il faut la merger et sur master et sur develop pour qu'elle puisse être repercutée dans tout le système.
Elles sont là pour éviter d'arrêter le développement pour de la maintenance.
Pour débuter une branche de hotfix avec git flow
git flow hotfix start branch_name
Avec git
git checkout master
git checkout -b branch_name
Pour terminer la maintenance avec git flow
git flow hotfix finish branch_name
Avec git
git checkout master
git merge branch_name
git checkout develop
git merge branch_name
git branch -D branch_name
III- Conclusion
Ce tutoriel est un bref résumé du fonctionnement de git flow qu'est aujourd'hui un outil intéressant pour faire du devops. Il vous aidera à sauver du temps et vous évitera des problèmes lourds en production ou en développement.