Cet article vise, d’une part, à faire une brève introduction à Git, un système de contrôle de version (VCS) et, d’autre part, à expliquer plus en détail en quoi consiste le flux Git, un flux de travail de travail qui permet une utilisation plus propre et plus professionnelle des capacités offertes par Git.
Après avoir lu cet article, vous pourrez implémenter GitFlow dans vos projets de développement et vous pourrez bénéficier de ses avantages lors de l’intégration de nouvelles évolutions, de la correction de bugs -hotfix- ou de la gestion des versions de code déployées dans les différents environnements, entre autres avantages.
Git, la base de tout
Git est un système de contrôle de version distribué créé en 2005 par Linus Torvalds, le créateur de Linux, avec l’objectif initial de gérer et intégrer les contributions apportées à l’époque au noyau Linux, qui était en plein développement. Au fil du temps, Git est devenu la référence des VCS distribués: des systèmes dans lesquels chaque machine qui partage le code partage également une copie mise à jour de l’ensemble du répertoire: de cette manière, la perte d’informations est évitée en cas de une défaillance du serveur central.
En ce qui concerne la licence, Git est un système qui utilise la licence de code libre GNU GPL, qui peut être utilisée sans licence.
Les 6 commandes de base de Git
git clone et git init
La commande git clone <URL> vous permet de récupérer un répertoire existant sur un serveur distant. C’est la commande de base lorsque nous voulons récupérer du code existant d’un serveur distant, comme GitHub ou Bitbucket, par exemple. Cette commande va créer un dossier avec le nom du répertoire remote et y copier tous les fichiers du répertoire.
Si vous souhaitez créer un répertoire git dans un dossier de notre système, il est nécessaire d’exécuter la commande git init, qui créera, entre autres, un dossier caché ‘.git’ avec toutes les informations relatives au nouveau répertoire créé.
git fetch et git pull
La commande git fetch vous permet de récupérer des fichiers et des informations à partir du répertoire distant. Il est d’abord nécessaire d’avoir un répertoire initialisé et un répertoire distant associé.
D’un autre côté, la commande git pull exécute la commande fetch expliquée anterieurement et combine également le contenu récupéré avec le contenu le plus récent de votre branche (ce qui est connu sous le nom de HEAD). Pour cette raison, la commande pull est beaucoup plus utilisée que fetch.
git checkout
La commande git checkout <BRANCH NAME> est sans aucun doute l’une des commandes git les plus importantes car elle permet de créer des branches ou d’utiliser des branches dans un répertoire locale. Tel qu’elle est écrite, la commande change la version actuelle du code pour la version contenue dans la branche avec ce nom. Mais, si nous ajoutons l’option -B (git checkout -B <BRANCH NAME>), nous créerons une nouvelle branche avec le nom spécifié dans la version actuelle pour, ensuite, la charger dans notre répertoire.
git add et git commit
Une fois qu’un répertoire a été créé et que nous avons ajouté des modifications, il est temps de les enregistrer dans Git, et pour cela nous devons utiliser git add et git commit.
La première commande, git add <FILES> est utilisée pour placer les nouveaux fichiers dans la zone de scène: c’est-à-dire pour faire git ‘voir’ ces fichiers.
La deuxième commande et, peut-être la plus connue, git commit <FILES> sont utilisées pour enregistrer ces modifications dans le répertoire local. Il est possible d’exécuter les deux actions en même temps avec la commande suivante: git commit -am « Commit message » <FILES>.
git merge
Nous savons comment créer des branches et modifier le code qu’elles contiennent, mais nous ne savons toujours pas comment fermer ces branches et integrer les modifications d’une branche à une autre. Pour cela, nous avons la commande git merge <BRANCH NAME>.
Cette commande vous permet d’apporter les modifications d’une branche spécifiée à la branche depuis la quelle vous exécutez la commande. Le conflit est une situation dans laquelle git n’est pas en mesure de déterminer quelles modifications doivent être préserves après une fusion: cela se produit lorsque le même fragment de code a été modifié dans les deux branches impliquées dans la fusion.
La situation de conflit permet au développeur de choisir quelle version de code doit résulter de la fusion des deux branches.
git push
Enfin, lorsque nous avons fini de modifier et d’intégrer le code, le moment est venu de publier nos modifications. Pour cela, nous utilisons la commande git push <REMOTE> <BRANCH>.
Cette commande vous permet de mettre à jour le répertoire remote avec les modifications de notre répertoire local et, en même temps, publier nos modifications pour que les autres développeurs d’équipe puissent les utiliser.
Ces 6 commandes vous permettent de travailler et d’utiliser Git pour gérer le code d’un projet. Cependant, lorsque nous commençons à avoir des environnements (environnement de développement, QA, préproduction, production, etc.) ou à devoir maintenir et prendre en charge différentes versions de la même application, disons que la chose devient compliquée.
Au début, cela peut sembler facile, lorsque nous travaillons avec une ou deux branches, mais à mesure que la charge de travail et les branches augmentent, la gestion du répertoire peut devenir un vrai chaos. Pour nous aider à éviter ce genre de situations, nous avons GitFlow à notre disposition.
GitFlow: la clé des grands projets
GitFlow est une méthode de travail avec Git basée sur la création de branches et qui vise à modéliser le workflow dans le projet de développement: des tâches de développement de nouvelles fonctionnalités ou de correction d’anomalies à la mise en production de nouvelles versions.
Pour le fait d’être une méthode de travail : il peut être facilement modifié et adapté pour répondre aux différents besoins d’un projet de développement ou de maintenance d’applications.
Master et develop, les branches de base de GitFlow
Un répertoire Git, par défaut, est initialisé avec une seule branche: master. C’est la branche par défaut et la plus importante: où l’on doit intégrer les autres branches que l’on crée pour implémenter de nouvelles fonctionnalités ou pour faire des corrections.
Cette idée change légèrement avec GitFlow. Selon la méthode GitFlow, master contient le code qui est actuellement déployé, c’est-à-dire, le code qui est en production et que les utilisateurs de l’application utilisent.
Pour intégrer les changements (nouvelles fonctionnalités, corrections, etc.) GitFlow propose une nouvelle branche develop.
Features: ajout de nouvelles fonctionnalités
Pour développer une nouvelle fonctionnalité, une feature doit être créée. Le nom de la branche est libre, bien qu’il soit recommandé d’utiliser le préfixe feature/ pour identifier rapidement le type de modification que contient la branche, sans avoir à voir le code.
git flow feature start FEATURE_ NAME
Une fois la fonctionnalité est terminée, il est temps de la fermer. Pour fermer la tâche -et la branche- et intégrer les changements dans develop, nous devons exécuter la commande suivante à partir de la branche de la fonctionnalité que nous allons fermer.
git flow feature stop FEATURE_ NAME
Hotfix: correction des erreurs de production
Un hotfix est une intervention que nous réalisons sur le code déployé en production dans le but de corriger une anomalie grave ou qui empêche le fonctionnement normal de l’application. Comme il s’agit d’une intervention sur le code en production, la branche que nous allons créer pour corriger le problème doit partir de master.
git flow hotfix start VERSION_HOTFIX
Dans ce cas, au lieu de spécifier un nom, nous devons indiquer la nouvelle version qui sera créée avec l’application de correctif. Lorsque l’équipe a terminé le correctif, il est temps de le fermer et d’intégrer les changements.
Dans ce cas, puisque l’origine de la modification est master, il est logique que nous intégrions le code dans master. Cependant, nous devons penser à étendre la correction à notre branche d’intégration pour éviter qu’elle ne réapparaisse à l’avenir: c’est pourquoi nous allons également l’intégrer dans develop. Enfin, un master tag correspondant à la nouvelle version du code sera créé généré.
git flow hotfix finish VERSION_HOTFIX
Release: création de versions
Dans chaque projet, il y a des moments où nous devons faire des «livraisons», c’est-à-dire que nous devons stabiliser, séparer et traiter – si nécessaire – le code afin qu’il puisse être déployé en production.
GitFlow facilite la deuxième étape: séparer ou identifier le code à livrer. Et pour cela, nous avons les versions.
git flow release start RELEASE_VERSION
La release est une tâche de branche spéciale que nous prendrons de develop et dans laquelle nous devons spécifiez la version que nous voulons créer (comme nous l’avons fait avec le hotfix). Cette branche est conçue pour stabiliser le code et corriger les anomalies que l’on trouve dans les tests effectués avant la fermeture de la version.
git flow release stop RELEASE_ VERSION
Lorsque tout sera prêt, nous fermerons la version avec la commande précédente. Cette commande intégrera le code dans master et se développera (comme c’est le cas avec le hotfix). Un tag sera également créée dans la branche principale pour baliser la nouvelle version créée.
Bugfix: correction des anomalies de développement
Un bugfix, contrairement à un hotfix, est une tâche consistant à corriger une anomalie pendant le développement. Par conséquent, la branche avec la correction, qui est créée à partir de develop ne sera intégrée qu’à develop. À des fins pratiques, leur comportement est le même que lorsque nous avons créé une feature. Pour créer un correctif, vous devez utiliser la commande suivante.
git flow bugfix start BUG_NAME
Une fois l’erreur est corrigée, pour intégrer les changements dans develop et fermer le bugfix, il faut utiliser la commande finish
git flow bugfix finish BUG_ NAME
| Source: nvie.com | Fonctionnement complet de GitFlow |
Adapter GitFlow à nos besoins
La mise en œuvre de la méthode GitFlow est une tâche simple car la grande majorité des projets informatiques ont une branche où ils intègrent le code puis les branches dans lesquelles des modifications sont apportées et qui sont intégrées dans la branche principale.
Passer de ce schéma au schéma proposé par GitFlow nécessite de créer une branche appelée develop, à partir de laquelle créer les branches pour implémenter les fonctionnalités et aligner le code en master avec la version actuellement déployé en production. Il s’agit, en somme, de mieux organiser l’utilisation du répertoire Git par l’équipe.
Cependant, dans les grands projets, l’application de GitFlow doit s’adapter aux besoins du projet et, dans cet article, nous verrons deux adaptations plus ou moins fréquentes qui peuvent être faites pour que 100% de notre projet utilise les directives GitFlow.
Environnements . Souvent, un projet logiciel a plus d’un environnement: des environnements tels que la qualification ou la pré-production sont normaux. Il s’agit généralement d’environnements dans lesquels des versions stables de code sont déployées pour les tests. Par conséquent, pour les intégrer à GitFlow, nous devons créer une branche avec le nom de l’environnement (par exemple, staging) et aligner le code de cette branche avec celui déployé dans l’environnement.
Il est recommandé d’utiliser les outils CI (intégration continue) pour automatiser les déploiements dans cet environnement lorsque la version de code présente dans la branche change. Enfin, GitFlow ne sait pas combien de branches d’environnement nous avons entre develop et master, ni leur rôle dans le projet, donc les branches de version et de hotfix ne seront pas intégrées dans ces branches lorsqu’elles seront fermées. Cela peut être fait via les commandes Git et à l’aide des outils CI.
Versions . Parfois, un projet doit conserver plusieurs versions d’un produit. C’est un cas typique de projets de maintenance. Dans ces cas, il n’y a pas un seul produit ou code en production mais il y en a autant que de versions considérées en fonctionnement et avec maintenance. Pour ces cas, il est conseillé de générer une branche et un environnement pour chaque version de code.
Partant d’une base de connaissances très basique, nous avons revu les commandes de base pour interagir avec un répertoire Git et introduit une méthodologie applicable à Git; GitFlow, qui vous permet de gérer des répertoires d’un point de vue plus fonctionnel, en gérant les évolutions (fonctionnalités) , les corrections (hotfix) ou encore les livraisons de versions de code ( release ).
De cette façon, nous avons appris une manière d’intégrer la gestion de code dans un projet de développement et / ou de maintenance informatique de manière technique et fonctionnelle . Enfin, nous avons vu que GitFlow est une méthodologie de base, à partir de laquelle des adaptations peuvent être faites en fonction des besoins spécifiques d’un projet.