Pré-requis : Découvrir les outils

Versioning de fichiers

Le versioning de fichiers consiste à conserver différentes itérations du même fichier. Nous faisons parfois cela à la main, en faisant des copies du même fichier et en ajoutant un numéro de version ou une date au nom des copies. Ainsi, on peut revenir à une version antérieure si nécessaire, ou retracer l’historique des modifications pour comprendre comment les choses en sont arrivées à ce point. Cela peut être crucial lorsqu’on travaille sur quelque chose qui prend beaucoup de temps pour atteindre un état parfait (par exemple des rapports ou du code logiciel). Cela peut aussi aider plusieurs personnes à travailler sur le même fichier, en gérant différentes versions pour chaque contributeur. Eh bien, la gestion du versioning de fichiers est une fonctionnalité intéressante. C’est encore mieux d’avoir un outil pour cela, et de ne pas le faire à la main.

Il existe de nombreux outils, mais nous nous concentrerons sur “git”, qui est aujourd’hui largement utilisé par les développeurs.

1 — Installation

Suivez les instructions officielles correspondant à votre ordinateur. Les options de configuration par défaut nous conviennent.

2 – Utilisation locale

Ouvrez votre interface de ligne de commande préférée et dites à “git” qui vous êtes (cela apparaîtra dans le journal des contributeurs lors de l’édition de fichiers).

$ git config --global user.name "Your Name"
$ git config --global user.email "you@imt-atlantique.net"

Veuillez remplacer par votre vrai nom et email, ne copiez-collez pas aveuglément…

Maintenant, créez un répertoire pour un projet factice (ici nommé git_trial_1) et initialisez-le pour git (avec git init) : cela crée des fichiers de configuration cachés.

$ mkdir git_trial_1
$ cd git_trial_1
$ git init

Puis, produisez des fichiers là-dedans, demandez à git de les gérer (en utilisant git add), produisez un premier “commit” (une version, avec git commit), et vérifiez que tout va bien à chaque étape (git status).

$ echo "Hello" > readme.txt
$ echo "print('hello world')" > hello.py
$ git status
$ git add *
$ git status
$ git commit -m "My first steps with git"
$ git status

Ensuite, faites un changement et produisez une nouvelle version.

$ echo "world" >> readme.txt
$ git status
$ git commit -a -m "Improved documentation"
$ git status
$ git log --stat

La commande git log affiche les différentes versions de votre projet. Notez que les commits sont identifiés par un nom unique aléatoire, pas un simple numéro. (Faire des contributions à un projet n’est pas quelque chose de strictement linéaire, mais ressemble plutôt à un graphe de tâches. C’est pourquoi utiliser des numéros n’aurait aucun sens.)

Notez que le tout dernier commit a pour surnom HEAD (HEAD~ est le commit d’avant, et HEAD~~ ou HEAD~2 comme le commit encore plus tôt, et ainsi de suite).

Pour savoir ce qui est arrivé à un fichier, on utilise la commande git blame :

$ git blame readme.txt

Si vous avez des doutes sur les changements de ce fichier et que vous voulez voir une version précédente, vous pouvez utiliser la commande git show :

$ git show HEAD~ readme.txt

Ce n’est probablement pas si évident au premier coup d’œil en regardant le résultat, mais en réalité git fait tout cela en appliquant des diffs, c’est-à-dire en maintenant les différences apportées à chaque version. Le cœur du processus est de calculer et d’appliquer des diffs sur les fichiers.

git est un outil de gestion de versions très puissant, nous n’avons présenté ici qu’une infime partie de ses capacités.

3 — GitLab

Vous pourriez être intéressé à héberger votre travail sur un serveur et à y pousser vos modifications. Cela permet de travailler avec d’autres personnes, ou avec vous-même mais depuis différents ordinateurs. Le serveur agit comme une sorte de point de synchronisation.

Vous avez peut-être déjà entendu parler de GitHub. Notez que git n’est pas GitHub. GitHub est un serveur pour les projets git de la société GitHub Inc., acquise par Microsoft en 2018. D’autres serveurs git sont disponibles. Il est donc important de savoir vers qui vous poussez votre travail.

IMT Atlantique offre un serveur GitLab à des fins éducatives. Connectez-vous et créez un projet, avec un nom comme git_trial_2. Vous pouvez utiliser un modèle prédéfini, par exemple “Sample GitLab Project” L’initialisation peut prendre une minute ou deux. Soyez patient. Le serveur, en plus de git, offre plusieurs fonctionnalités telles qu’un wiki, un espace web, des tickets, etc. : un ensemble d’outils utiles pour le développement logiciel collaboratif.

Dans le coin supérieur droit de votre page de projet, il y a un bouton bleu nommé “Code”. Développez le menu associé. Plusieurs façons de cloner/ouvrir/télécharger votre projet sont proposées. Choisissons “Clone with HTTPS”. Gardez l’URL fournie dans votre presse-papiers.

Ouvrez votre interface de ligne de commande préférée, déplacez-vous dans le répertoire souhaité et clonez ce projet GitLab sur votre ordinateur.

$ git clone https://gitlab-df.imt-atlantique.fr/xxxx

Utilisez l’URL fournie depuis votre presse-papiers (et non le ‘xxxx’ ci-dessus).

Vous pouvez maintenant aller dans ce répertoire de projet, faire tous les changements dont vous avez besoin, localement sur votre ordinateur, faire des commits et d’autres tâches git sophistiquées, et occasionnellement pousser cela vers le serveur. La commande correspondante est git push, et son amie git pull. Vous pouvez faire cela depuis plusieurs ordinateurs.

Lors de ces opérations de synchronisation, il est possible que des conflits surviennent si plusieurs personnes modifient le même fichier en même temps. Un conflit se produit lorsque deux modifications incompatibles sont apportées à la même ligne d’un fichier. Notez que nous n’avons pas l’intention de détailler ici comment résoudre des conflits de fusion complexes. Cependant, sachez qu’il existe des outils et des stratégies pour vous aider à gérer ces situations. Mais si vous travaillez sur des fichiers séparés, sur des parties séparées de fichiers, ou si vous suivez la séquence stricte pull-commit-push, il n’y aura probablement pas de problème.

$ cd git_trial_2
$ git pull
$ echo "foo bar" >> doc.txt
$ git add doc.txt
$ git commit -m "add documentation"
$ git push

Notez que les commandes push et pull fonctionnent parce que ce projet git a été configuré avec une URL. Vous pouvez vérifier cette URL avec la commande suivante :

$ git remote get-url origin

Votre premier projet git_trial_1 n’a pas d’URL distante. Associons-le à un projet GitLab. Connectez-vous au serveur GitLab. Créez un autre projet, avec un nom comme “git_trial_1”. Mais cette fois il est très important de choisir “Create a blank project”. Ensuite, GitLab fournit quelques conseils sur comment connecter votre projet local à celui de GitLab. Ouvrez votre interface de ligne de commande préférée et suivez-les. Là encore, pensez à adapter l’URL à votre propre projet :

$ cd git_trial_1
$ git remote add origin https://gitlab-df.imt-atlantique.fr/yyyy
$ git branch -M main
$ git push -uf origin main

Vous pouvez maintenant aller dans ce répertoire de projet, faire tous les changements dont vous avez besoin, localement, faire des commits et d’autres tâches git sophistiquées, et occasionnellement pousser cela vers le serveur…

4 — Conclusion

Ces premiers pas avec git sont une introduction très minimaliste. Ceci est suffisant pour un contexte mono-utilisateur, pour de petits projets, sans conflits complexes d’édition de fichiers. Mais cela peut couvrir la plupart de nos besoins pour l’instant. Plus de documentation depuis le tutoriel officiel ou depuis des tiers. Vous pourriez apprendre comment créer des branches, des tags, des fusions et bien d’autres choses fabuleuses.