[Article de vulgarisation de sujet tech]
Qu'est-ce que Git ?
Git est un système de gestion de versions du code, qui permet de suivre les modifications apportées au code d'un projet tech.
C’est la bonne pratique numéro 1 de tout projet tech : git est mis en place au premier jour du projet, peu importe le type de projet (web, software, data, R&D…).
C’est utile pour 3 raisons notamment que l’on détaillera plus bas :
- Collaboration: permettre aux devs de travailler simultanément sur le même code
- Historisation: Avoir la possibilité de revenir à une version précédente du code
- Qualité: Intégrer des couches de qualités pour assurer la pérennité du projet
Il y a 3 concepts majeurs de git qu’il faut comprendre :
- Un commit est une modification apportée au code (e.g. quand un dev rajoute une fonctionnalité ou corrige un bug).
- Une branche est une succession de commits
- Par exemple, la branche principale d’un projet contient une succession de commits qui mis bout-à-bout donnent le code à jour.
- Un repository contient l’ensemble du code versionné par git. Ce repository va être hébergé dans le Cloud la plupart du temps (ça peut aussi être hébergé en local, mais c’est rare), sur des services comme Github, Gitlab,...
Exemple Github de repository open source. On y voit par exemple :
Pourquoi git est si utile ?
Comme vu plus haut, Git permet d’améliorer la collaboration, l’historisation et la qualité.
Collaboration
- Les développeurs peuvent travailler sur des branches parallèles pour tester de nouvelles fonctionnalités sans affecter la version principale du projet.
- Git permet aussi de gérer les conflits, e.g. si 2 développeurs modifient le même bout de code en travaillant en parallèle.
- Quand un nouveau développeur arrive sur le projet, il peut facilement récupérer l’état actuel du code.
Historisation
- Si un bug arrive en production, on peut facilement revenir à une version précédente du code.
- Un bout de code supprimé par le passé peut être récupéré par le développeur.
- L’analyse de bugs est aussi facilitée, en analysant l’historique des évolutions du code.
- Une expérience / développement non fructueux peut être historisé au cas où le projet nécessite de le récupérer plus tard.
Qualité
- L’utilisation de git facilite la mise en place de code review: c’est essentiel pour maintenir un bon niveau de qualité sur le projet.
- Des outils comme la CI-CD sont conçus pour être utilisé avec git:
- La CI (Continuous Integration) est généralement déclenchée à la création d’une pull request. Elle check que le code que le développeur essaie de merger se conforme aux standards de qualité du projet et limite le risque d’ajout de bugs via des tests.
- La CD (Continuous Development) est généralement déclenchée une fois qu’une pull request est mergée. Elle permet de “déployer” automatiquement le code qui vient d’être mergé.
Exemple d’utilisation de git
Pour mieux comprendre, voici le flux classique de dev avec git sur un projet tech.
Contexte : Alice et Pierre sont tout 2 développeurs sur un projet. Ils traquent leur code dans un repository git hébergé sur GitHub.
Ce repository contient deux branches :
- Une branche development qui contient le code déployé sur l’environnement de développement (i.e. de test en quelque sorte)
- Une branche production qui contient le code déployé sur l’environnement en production (accessible par les utilisateurs)
Développement d’une nouvelle fonctionnalité étape par étape
- Alice crée une nouvelle branche feature qui part de la branche development
- Cela revient à dupliquer la branche development
02. Alice rajoute du code pour implémenter une fonctionnalité et crée un ou plusieurs commits pour chacun de ses changements.
03. Elle “pousse” sa branche dans GitHub (dans le cloud) : cette action consiste à mettre ses développements initialement dans son environnement local (sur son ordi), dans le repository Github accessible par toute l’équipe
04. Alice veut maintenant amener les modifications faites sur sa branche feature dans la branche development, i.e. rajouter les commits de la branche feature sur la branche development. Elle crée donc une pull request, qui va mettre en exergue les modifications apportées.
- Pierre, son co-dev va pouvoir relire ces modifications pour les valider ou lui faire des retours. La code review permet de repérer d’éventuelles erreurs et d’assurer la qualité du code sur le long terme, pour faciliter les développements futurs et limiter les bugs.
Alice prend en compte les éventuels retours de Pierre en rajoutant des commits.
- Une fois que Pierre valide les changements d’Alice, les modifications de la branche feature sont apportées dans la branche development.
6) Le code est mis en production : les modifications de la branche development sont apportées dans la branche production.
Pour pratiquer
Si vous êtes familier avec le terminal, vous pouvez vous lancer dans ce tuto pour pratiquer git: https://learngitbranching.js.org/?locale=fr_FR (les niveaux 1 - 2 - 3 et 4 de “Séquence d’introduction”).
Vous recherchez des experts en Data Management ? N'hésitez pas à nous contacter !