Git et la Console - partie 1

Découvrir Git en toute tranquillité


Git, un VCS décentralisé

Série « Git et la Console »

Cet article est le premier d'une série dédiée à Git, dans le but d'offrir une synthèse des notions essentielles à comprendre lorsqu'on le découvre, ainsi que quelques bonnes pratiques à respecter. Je ne prétends pas livrer ici une alternative à la documentation officielle, qui a le mérite d'être bien écrite et devrait être lue en priorité. Voyez plutôt ces quelques chapitres comme un complément à votre apprentissage. Complément qui je l'espère pourra vous aiguiller un peu quant à la façon dont vous utiliserez Git.

Après une découverte progressive des bases, nous évoquerons les méthodes efficaces parmi celles qui existent, comment s'adapter, comment régler les cas de conflits, comment les prévenir. Nous verrons pourquoi une bonne compréhension des mécanismes internes à Git lui-même facilite grandement l'adoption de toutes ces solutions.

Au passage, ce sera aussi l'occasion de découvrir les bases de la console puisque nous manipulerons Git exclusivement en ligne de commande. Et tant qu'à faire nous utiliserons une console moderne avec Windows Terminal.

Les chapitres suivants sortiront progressivement :

  1. Git, un VCS décentralisé
  2. Initiation à la ligne de commande
  3. Les bases du versionnement avec Git
  4. Manipuler l'historique, les branches et les tags
  5. Fusionner des versions et résoudre les conflits
  6. Communiquer avec les dépôts distants
  7. Travailler à plusieurs efficacement
  8. Conclusion et au-delà

Sommaire

  1. Le versionnement en informatique
  2. Les Version Control Softwares
  3. Le VCS le plus utilisé : Git
  4. Les avantages et inconvénients de Git
  5. Installation de Git

1 - Le versionnement en informatique

La Gestion de versions, vulgairement appelée versionnement, consiste à créer et gérer différentes versions d'un même projet.

Ces versions peuvent être des étapes dans la vie du projet, par exemple v1.0.0, v2, etc. Pour les besoins du tuto, nous appellerons ce type de versions des versions chronologiques. Quand on travaille avec Git, elles correspondent aux tags.
Mais les versions peuvent aussi être des versions spécifiques du projet dédiées à des besoins précis, par exemple master, develop, test, etc. Pour les besoins du tuto, nous appellerons ce type de versions des versions spécifiques. Quand on travaille avec Git, elles correspondent aux branches.
Nous découvrirons ensemble ces concepts dans le module 4.

L'ensemble des versions constitue un historique, nous permettant de suivre l'évolution du projet à travers le temps, depuis sa création jusqu'à son état actuel, en passant par toutes les versions alternatives, temporaires ou spécifiques qui pourraient exister.
On cherchera souvent à naviguer au sein de cet historique, c'est à dire à modifier notre projet pour qu'il corresponde à une version précise. Avec git, c'est la commande git checkout qui nous permettra ceci. Nous verrons également cette commande dans le module 4.

On aura aussi régulièrement besoin de fusionner différentes versions, ce qui pourra éventuellement entrainer des conflits qu'il faudra savoir résoudre. Le module 5 sera dédié à ces notions avec la découverte des commandes git merge et git rebase.

Enfin, l'intérêt du versionnement est bien souvent de faciliter le travail à plusieurs. Les modules 6 et 7 se concentreront sur ce besoin en abordant la communication avec les dépôts distants et en présentant plusieurs workflows permettant d'organiser le travail en commun.

Tous ces besoins peuvent s'avérer complexes à gérer au quotidien, surtout sur de gros projets avec beaucoup de développeurs impliqués. C'est pourquoi on a recours à des solutions logicielles. On parle ici des fameux Version Control Softwares (ou Systems), dont Git est le représentant le plus populaire.

2 - Les Version Control Softwares

Les Version Control Softwares (ou Systems) sont nombreux, et bien plus anciens que Git lui-même. S'ils sont historiquement très utilisés dans le logiciel libre et l'open-source, de nos jours leur usage s'est généralisé à l'ensemble du développement informatique. Bien que la plupart d'entre-eux utilisent nombre de concepts communs, chacun a ses particularités le rendant plus ou moins adapté aux différents projets et aux différentes équipes. Par exemple certains sont centralisés quand d'autres, à l'image de Git, sont décentralisés (ou "distribués"). L'apparition de Git a cependant permis de gommer les quelques lacunes et faiblesses de ses prédécesseurs, le propulsant jusqu'à la position de VCS le plus populaire et le plus utilisé à travers le monde.

Ce que l'on attend d'un bon VCS c'est avant tout de satisfaire les besoins évoqués précédemment. À savoir :

  • On doit pouvoir créer facilement de nouvelles versions et de nouvelles modifications
  • On doit avoir accès à un historique compréhensible : on doit pouvoir savoir facilement qui a fait quoi et quand
  • On doit pouvoir facilement revenir en arrière, effacer des modifications, en fusionner...
  • Les cas de conflits entre différentes versions doivent être les moins fréquents possibles, et simples à résoudre
  • Le travail à plusieurs et à distance doit être facilité en toute circonstance et pour tout type d'équipe

Pour satisfaire ces besoins, beaucoup de VCS ont recours aux principes de commit, d'historique, de tag et de branche.

Les commits, en français appelés simplement modifications, sont des enregistrements des modifications apportées aux fichiers du projet. On peut en quelque sorte les considérer comme des sauvegardes du travail effectué. C'est la suite des commits dans le temps qui nous permet d'accéder au fameux historique de l'évolution de notre projet.

Comme on l'a vu précédemment, les tags correspondent aux versions chronologiques du projet. Ils sont un moyen d'identifier un commit précis comme correspondant à une version précise. Il n'est pas nécessaire de créer un tag pour chaque commit : c'est vous qui décidez quand un commit doit correspondre à une version, version que vous définissez, en créant un tag avec un numéro de version : v0.0.1 > ... > v1.0.0 > v1.0.1 > ... > v1.1.0 > ...

Les branches quant à elles sont des versions "concurrentes" ou "parallèles" d'un même projet, c'est-à-dire les versions spécifiques dont nous parlions précédemment. Ces branches peuvent coexister et/ou être fusionnées.

Par exemple : la branche master ou main représente souvent la version stable d'un projet. Celle testée, sans bug, utilisable. Par opposition, la branche develop représente souvent la version qui centralise tous les développements en cours. Typiquement, lorsque ces développements sont terminés et testés, on voudra les fusionner dans la branche master afin de faire évoluer la version stable du projet.

Un bon VCS doit donc faciliter toutes ces opérations, le tout sans nous limiter dans les possibilités d'évolution du projet et des différentes versions le constituant.

Mais un bon VCS doit également être rapide. Une gestion de versions correctement effectuée a recours à des manipulations très fréquentes. On doit souvent sauvegarder notre travail, souvent récupérer le travail des autres, souvent fusionner les deux ensemble. Comme ces opérations sont très fréquentes dans la journée d'un développeur, il est rare que ce dernier apprécie de perdre du temps chaque fois que ces étapes se renouvellent.

3 - Le VCS le plus utilisé : Git

Linus Torvalds, créateur de Git et du noyau Linux
Linus, Père spirituel des Manchots

C'est à Linus Torvalds, le papa du noyau Linux, que l'on doit également la création de Git.

L'équipe de développement du noyau Linux versionnait historiquement son code à l'aide du VCS BitKeeper, jusqu'à ce que l'éditeur de celui-ci cesse brutalement de fournir la version gratuite en 2005. Linux étant un projet libre, il était important pour l'équipe de remplacer BitKeeper par un outil qui ne soit pas propriétaire. Ils étaient donc dans le besoin d'une alternative. Et c'est ainsi que Linus commença à travailler sur le développement de Git, le VCS qui surpassera bientôt tous les autres.

Ce qui a fait le succès de Git, c'est à la fois sa souplesse dans la gestion des branches, sa rapidité d'exécution, et son modèle distribué (ou décentralisé) qui facilite grandement le travail à plusieurs. Ainsi que bien évidemment le fait que son code soit libre et accessible à tous.

Enfin, c'est l'incontournable Github qui apporta l'ultime vague de popularité à Git. Aujourd'hui détenu par Microsoft, Github est le site qui héberge et centralise la majorité des projets libres et open-source du monde. Ce qui n'est possible que parce que le site s'appuie très fortement sur le VCS créé par Linus Torvalds. Github, par son importance, constitue à lui seul un argument en faveur d'une maîtrise de Git pour tout développeur actuel.

Logo du VCS Git
Git, un VCS pour les gouverner tous

4 - Les avantages et inconvénients de Git

Nous avons déjà évoqué plusieurs raisons du succès de Git, mais résumons un peu ses avantages par rapport aux autres VCS :

  • Par sa souplesse, Git rend très facile de créer et travailler avec des branches
  • Git compare nos fichiers ligne par ligne et non fichier par fichier
  • Il propose une gestion intelligente et non-bloquante des conflits
  • Il est décentralisé (ou "distribué") : il n'y a pas de serveur principal
  • En conséquence de l'aspect décentralisé, Git est très facile à mettre en place
  • Git est très rapide, c'est un plaisir de l'utiliser
  • Le plus : la documentation officielle est très bien faite

Ce serait presque le VCS parfait s'il ne venait pas avec trois inconvénients principaux :

  • L'aspect décentralisé amène majoritairement des avantages. Mais un grand pouvoir implique de grandes responsabilités : s'il n'y a pas de serveur principal, alors chaque participant au projet peut tout faire. Tout le monde a la possibilité de fusionner des versions aussi bien que de les faire disparaître. C'est-à-dire que chaque participant au projet a la possibilité de faire disparaître du code... Une simple erreur pouvant coûter très cher (littéralement : votre code est le produit de vos heures de travail), il convient d'utiliser Git avec prudence et en sachant ce que l'on fait.
  • Git étant très souple, il existe souvent plusieurs façons d'aboutir au même résultat, ou à un résultat similaire. En revanche dès lors que l'on travaille à plusieurs sur le même projet, il devient très important que chacun utilise la même méthode que les autres. Des conventions et des bonnes pratiques sont donc très utiles, et sont susceptibles d'être différentes à chaque équipe et/ou projet. Dans le module 7 nous aborderons les méthodes les plus utilisées ainsi que les bonnes pratiques que l'on peut en tirer.
  • Git est, c'est un fait, plus difficile à comprendre et à maîtriser que d'autres VCS. Son apprentissage demande sérieux, implication et mise en pratique dans la précaution. C'est en partie ce qui me pousse à écrire ce tuto/cours, j'espère qu'il pourra compléter cet apprentissage parfois compliqué.
La formation du nouveau - web comic par CommitStrip
CommitStrip rendant hommage à Git

5 - Installation de Git

Pour installer Git sous Windows, vous pourrez trouver un programme d'installation à télécharger sur sur le site officiel.

L'installeur vous demande de choisir plusieurs choses, nous allons donc les passer en revue ensemble :

Première étape de l'installation de Git
Pour cette première étape "Select Components", vous pouvez tout cocher par défaut. Si vous ne souhaitez pas d'icône pour Git sur le bureau, vous pouvez décocher l'option "On the Desktop".
Deuxième étape de l'installation de Git
Pour cette deuxième étape on vous demande de choisir l'éditeur de texte associé à Git. Je vous conseille ici de choisir votre éditeur de texte habituel. L'éditeur proposé par défaut, Vim, peut s'avérer pratique en ligne de commande, mais vous serez certainement comme moi plus à l'aise avec Visual Studio Code ou un équivalent.
Troisième étape de l'installation de Git
On vous demande ici le nom de la branche par défaut pour les nouveaux projets Git. Par défaut, et historiquement, il s'agit de master. En revanche certaines équipes et certains services, dont Github, préfèrent appeler cette branche main. Vous pouvez donc choisir ce qui vous convient le mieux. Aucun choix ne sera bloquant de toute façon. Si vous ne savez pas quoi choisir, vous pouvez laisser l'option par défaut, "Lest Git decide".
Quatrième étape de l'installation de Git
Cette quatrième étape consiste à choisir où vous souhaitez pouvoir utiliser Git. Je vous conseille de choisir l'option du milieu ici : "Git from the command line and also from 3rd-party software".
Cinquième étape de l'installation de Git
Vous devez ici choisir la librairie utilisée par Git pour les connexions sécurisées. Je vous conseille de laisser OpenSSl.
Sixième étape de l'installation de Git
Sixième étape : vous devez faire un choix concernant la façon dont Git va gérer les sauts de lignes dans vos fichiers. Ces derniers étant différents sur Windows et Linux, il est important que tous les participants au projet utilisent le même format au moment où ils sauvegardent leur travail dans un commit. On sauvegarde donc généralement nos commits avec le format de sauts de ligne propre à Linux. Comme vous travaillez sur Windows, Git va devoir convertir les caractères de saut de ligne avant chaque commit. Je vous recommande donc, là aussi, de laisser le choix par défaut : "Checkout Windows-style, commit Unix-style line endings".
Septième étape de l'installation de Git
Il vous faut ensuite choisir le terminal que vous souahitez utiliser par défaut avec Git Bash. Ce dernier n'est en effet pas un vrai terminal lui-même, il utilise MinTTY qui est un émulateur de terminal Linux. Afin de suivre la suite de ce cours, notamment le module suivant, il est important que vous conserviez cette première option : "Use MinTTY (the default terminal of MSYS2)".
Huitième étape de l'installation de Git
Ensuite, choisir le comportement de la commande git pull, que nous verrons dans le module 6. Je vous recommande une fois de plus de conserver l'option par défaut ici : "Default (fast-forward or merge)"
Neuvième étape de l'installation de Git
Il vous faut maintenant choisir l'outil que Git utilise pour gérer vos connexions aux services distants (Github, Gitlab, Bitbucket, etc). Laissez encore l'option par défaut ici : "Git Credential Manager Core".
Dixième étape de l'installation de Git
On y est presque ! Laissez là aussi les options par défaut.
Onzième étape de l'installation de Git
Enfin, dernière étape ! Et toujours aucun suspense : laissez par défaut (donc ne cochez pas la case).

Après ce calvaire consistant à cliquer une douzaine de fois sur le bouton "Next", nous voilà prêts : Git est installé sur votre machine !

Nous en resterons donc là pour aujourd'hui, et poursuivrons la prochaine fois avec une initiation à la ligne de commande.

L'installation de Git est terminée
Git est installé ! Nous sommes maintenant prêts à nous confronter à la console