Git est un système de Gestion de Version décentralisé très populaire et utile pour le suivi, la gestion du cycle de vie d’une application, le travail collaboratif et la gestion des risques.
GIT permet de conserver l’historique des versions dans un dépôt (repository), c’est-à-dire l’intégralité des états successifs (« révision ») de chaque fichier.
Il est très utile:
· Pour revenir facilement et à tout instant en arrière, en récupérant les fichiers d’un état précédent. Cela peut représenter une part non négligeable du (sur)coût en cas d’absence de système de Gestion de Version.
· Pour suivre l’évolution d’un fichier texte ligne de code par ligne de code
· Pour ajouter, modifier, supprimer les fichiers,
· Pour gagner du temps et de l’efficacité dans la livraison,
· Pour faciliter le travail collaboratif et gérer correctement:
· les modifications concurrentes des fichiers,
· la fiabilité du code conservé, et ne permettre que les changements autorisés,
· Pour identifier rapidement les impacts, car on peut faire de la vraie relecture de code a priori très simplement avec la gestion des branches simplifiés
Git est un système de Gestion de Version distribué (ou décentralisé), ce qui veut dire qu’il présente des différences notables avec les systèmes de Gestion de version centralisé comme SVN.
· En premier lieu, comme il est distribué, il considère chaque dépôt comme l’égal d’un autre,
· Il ne nécessite pas un serveur pour fonctionner, Il est donc plus pratique car il peut fonctionner en local.
· Pour la même raison d’utilisation de ressources locales, il est également plus rapide et performant.
Un point important des systèmes de gestion de Version est la gestion des Branches et des Tags. Avec GIT c’est plus simple, plus rapide, et plus clair.
· Pour rappel, la gestion des branches permet de mener en parallèle plusieurs versions
· Avec GIT, les branches retrouvent leurs sens propre (par rapport aux habitudes de SVN), à savoir un commit avec 2 descendants qui représentent une bifurcation (temporaire ou définitive) de la vie d’un projet.
· C’est souvent plus rapide pour créer et changer de branches quand le développeur travaille sur un dépôt local,
· Il est ainsi possible de personnaliser différents workflows. La proposition suivante étant souvent utilisée et contient 4 types de branches sur un projet :
· La branche master, réservée aux versions officielles, correctement taggées.
· La branche develop, qui contient la version courante fonctionnelle en cours de travail. Elle doit être livrable en l’état à n’importe quel moment.
· Les branches de release, qui partent de develop et seront fusionnées (mergées) sur master et permettent de finaliser une future version. Elles ne doivent contenir que des bugfixes, pas de nouvelles fonctionnalités.
· Les branches de feature, qui partent de develop. Elles correspondent au développement d’une fonctionnalité unique. Elles seront mergées à develop après une revue de code.
· La gestion des tags est utile car on peut donner un nom explicite à une version pour pouvoir y accéder facilement.
· Les tags deviennent de véritables étiquettes, c’est-à-dire qu'ils nomment un commit bien précis. Un tag n’est pas une simple copie de répertoire.
Pour faciliter le travail collaboratif sur différents projets, nous conseillons de coupler l’utilisation de GIT à un outil de gestion de dépôts (repositories).
Ces outils permettent d’étendre les fonctionnalités de GIT afin de faciliter la communication entres développeurs, comme par exemple :
· signaler des problèmes de code en déclarant des "issues",
· faire relire et valider son code en faisant des "pull requests" gérés ici de façon automatique,
· encore récupérer du code depuis un autre dépôt
· coupler avec des outils automatisés pour le déploiement.
GitHub ou Gitlab sont 2 exemples très utilisés.
Pour en savoir plus sur GIT :
https://git-scm.com/book/fr/v2
