Introduction

Git est l'un des systèmes de gestion de version les plus utilisés (également appelé, comme dans VS Code, SCM : gestionnaire de code source).

Motivation

Supposons que vous ayez terminé un projet que vous devez présenter à vos professeurs. Pour certaines raisons, votre présentation est reportée au mois prochain. La veille de votre présentation, vous vérifiez le dossier qui contient les fichiers de votre projet.

• Vous souvenez-vous encore du document qui est le vrai rapport final ?
• Quel fichier contient la présentation associée ?
• Quel livrable allez-vous remettre à vos professeurs ?

Bien que vous puissiez vérifier les dates de création et de modification des fichiers, vous ne pouvez pas vous y fier car elles sont gérées par le système de fichiers et vous ne contrôlez pas la manière dont elles sont définies. Par exemple, si vous créez une copie d'un fichier, les dates de création et de modification de la copie seront identiques à celles du fichier original. La date de modification peut également être modifiée par mégarde, par exemple lorsque vous ouvrez un fichier pour en vérifier le contenu et que votre application est configurée pour l'enregistrement automatique.

Une solution pour garder une trace des différentes versions des fichiers serait de suivre strictement certaines règles, telles que l'utilisation d'un dossier différent pour chaque nouvelle version, ou l'utilisation systématique de dates dans les noms de fichiers. Cependant, il est incroyablement facile d'oublier d'appliquer ces règles de manière cohérente pour les "petits changements", et lorsque le travail sur les différents fichiers n'est pas synchronisé. Le défi est d'autant plus complexe lorsque plusieurs personnes collaborent sur un même projet.

Le problème est encore plus grave dans le domaine du développement de logiciels : pendant que vous travaillez sur une nouvelle fonctionnalité, un bug critique peut être signalé sur la version précédente. Comment pouvez-vous corriger le bug si vous ne disposez pas d'une copie de la version précédente ?

Ces considérations nécessitent des outils pour gérer efficacement ces situations. Le premier outil de ce type, connu sous le nom de Source Code Control System (SCCS), a été créé en 1972 ; Git est le successeur de nombreux systèmes de gestion de version antérieurs.

Terminologie et fonctionnalités d'un gestionnaire de versions

Un gestionnaire de versions typique offre les fonctionnalités suivantes :

• Suivre toutes les modifications apportées aux fichiers sous contrôle (l'historique). Ainsi, vous pouvez avoir une liste de tous les changements et, pour chaque changement, vous connaissez exactement la date, l'heure, l'auteur et une description. Vous pouvez également revenir à une version antérieure de n'importe quel fichier et comparer deux versions différentes d'un fichier. L'endroit où le gestionnaire de versions conserve ces modifications s'appelle un dépôt.
• Permettre la collaboration de plusieurs développeurs sur un même projet. Chaque développeur est identifié par un compte et dispose d'un ensemble de droits (par exemple, créer de nouveaux fichiers) sur le dépôt.
• Permettre aux développeurs de décider quand les modifications d'un fichier sont placées sous le contrôle du gestionnaire de versions : cette opération est connue sous le nom de commit (ou validation).
• Fusionner (merge en anglais) différentes modifications faites sur le même fichier. Cela permet à deux développeurs de travailler sur le même fichier en même temps, sans qu'il soit nécessaire que l'un impose un verrou sur le fichier pour empêcher les autres d'y accéder. Les modifications ne sont automatiquement fusionnées que si elles n'entraînent pas de conflits, auquel cas les développeurs doivent intervenir.
• Étiqueter (tag en anglais) un ensemble de fichiers comme appartenant à la même version.
• Créer une copie gérée (aussi appelée branche) d'un projet qui peut être modifiée indépendamment de la version originale (aussi appelée branche principale ou main). La création d'une branche est utile lorsque vous souhaitez ajouter une nouvelle fonctionnalité à votre application sans impact sur la version actuelle. Lorsque la nouvelle fonctionnalité est prête et testée, vous pouvez fusionner la nouvelle branche avec la branche principale. Cela permettra d'intégrer la nouvelle fonctionnalité dans la version actuelle.

Il existe deux familles de gestionnaires de versions :

• Gestionnaires centralisés. Le dépôt est stocké sur un serveur. Lorsque vous voulez faire un commit, vous avez besoin d'une connexion réseau pour communiquer avec le serveur. Le commit est refusé s'il entraîne des conflits. CVS et SVN entrent dans cette catégorie.
• Gestionnaires distribués. Les développeurs disposent chacun d'un dépôt local sur leur machine, ils peuvent ainsi faire des commit même en l'absence de connexion réseau. Un dépôt distant est disponible, vers lequel les développeurs téléchargent leurs modifications locales, afin qu'elles soient visibles par les autres. Étant donné que deux développeurs peuvent avoir modifié les mêmes fichiers, le téléchargement peut entraîner des conflits qui doivent être gérés. Mercurial et Git appartiennent à cette famille.

Git

Git est un système de gestion de version distribué, largement utilisé aujourd'hui, notamment parce qu'il est disponible sur des serveurs (GitHub et GitLab pour citer les plus connus) qui peuvent être utilisés gratuitement pour des projets open source. Il a été conçu par Linus Torvalds, le principal développeur du noyau Linux.

Un point important dans la conception de Git est que la création d'une branche est une opération très légère car un fichier n'est pas réellement copié tant qu'il n'est pas modifié. Cela encourage la création de nouvelles branches chaque fois qu'un changement est nécessaire ; après avoir appliqué, testé et, dans les projets importants, revu et approuvé tous les changements, la nouvelle branche peut être fusionnée dans la branche principale, ou main.

Git étant distribué, les développeurs disposent chacun sur leur machine d'un dépôt local (local repository en anglais) contenant tous les fichiers du projet. En d'autres termes, les développeurs disposent chacun d'une copie locale du projet. Étant donné que les développeurs collaborent généralement sur un projet, ils doivent également disposer d'une copie partagée du projet, également appelée dépôt distant (remote repository en anglais), disponible sur un serveur (tel que GitHub ou GitLab).

La figure suivante illustre le fonctionnement de Git.

• Les développeurs créent un dépôt local sur leur machine en clonant un dépôt distant.
• Suite au clonage du dépôt distant, les fichiers de la branche principale du dépôt distant apparaîtront sur la machine du développeur avec un répertoire nommé .git. Les fichiers forment ce que l'on appelle l'espace de travail (workspace en anglais), tandis que le répertoire .git est le dépôt local (contenant toutes les branches et les différentes versions du projet).
• Le développeur peut éditer les fichiers de l'espace de travail.
• Le développeur ajoute à l'index les fichiers qui doivent être inclus dans la prochaine version du projet. Si le développeur a modifié les fichiers a.py, b.py et c.py, mais que seules les modifications dans a.py, b.py feront partie de la prochaine version, le fichier c.py ne sera pas ajouté à l'index.
• Le développeur fait un commit des modifications ajoutées à l'index. Cette action crée une nouvelle version du projet dans le dépôt local.
• Avant de publier les modifications sur le dépôt distant, le développeur récupère (pull en anglais) les dernières modifications depuis le dépôt distant. Cela peut révéler des conflits avec les modifications locales, que le développeur doit résoudre avant de continuer.
• Enfin, le développeur publie (push en anglais) les modifications locales sur le dépôt distant.

Dans ce laboratoire, et dans les activités des Coding Weeks, vous aurez toujours un dépôt distant et un ou plusieurs dépôts locaux. Le dépôt distant sera géré par un serveur GitLab disponible à CentraleSupélec. Notez que disposer d'un dépôt distant est toujours une bonne idée, même si vous travaillez seul sur un projet : il sert de sauvegarde et vous permet d'accéder aux fichiers de votre projet sur n'importe quel ordinateur.

Activité

Avant de poursuivre, assurez-vous que VS Code est toujours en cours d'exécution et que votre répertoire de travail dans le terminal est ~/Documents/sip/sip_td_computer ; ce répertoire doit contenir un fichier nommé hello.py.

• Connectez-vous au serveur CentraleSupélec GitLab en utilisant votre adresse email CentraleSupélec comme nom d'utilisateur et votre mot de passe habituel.
• Cliquez sur le bouton bleu Nouveau projet, puis sur Créer un projet vide.
  
  
• Nommez votre projet sip_td_computer_git, décochez la case Initialiser le dépôt avec un README et cliquez sur le bouton bleu Créer le projet.
  
  
• Copiez/collez les deux lignes du paragraphe Configuration globale de Git dans le terminal VS Code. Vous n'aurez pas besoin de le faire la prochaine fois que vous créerez un nouveau dépôt.
  
  
• Tapez la commande suivante pour demander à Git d'utiliser Visual Studio Code lorsque la fusion de branches génère des conflits.
  
  

git config --global core.editor "code --wait"

Puisque nous voulons créer un nouveau projet, regardez les commandes listées dans le paragraphe Créer un nouveau dépôt. Voici une explication de chacune d'entre elles :

• git clone https://gitlab-student.centralesupelec.fr/<username>/sip_td_computer_git.git (<username> étant remplacé par votre propre nom d'utilisateur):
  La commande git clone est utilisée pour faire une copie locale du dépôt Git distant.

Avant de taper la commande, changez le répertoire de travail dans le terminal pour qu'il pointe vers le parent du répertoire courant.

Votre répertoire de travail devrait maintenant être sip.
Copiez/collez maintenant la commande git clone. Il vous sera demandé d'insérer votre nom d'utilisateur (votre adresse électronique CS) et votre mot de passe. Si tout se passe bien, un message vous informera que vous avez cloné avec succès un dépôt vide, ce qui est correct.

• cd sip_td_computer_git:
  si vous regardez le contenu de votre répertoire de travail dans le terminal VS Code (qui devrait être ~/Documents/sip), vous devriez voir les deux dossiers sip_td_computer et sip_td_computer_git.
  Ouvrez dans VS Code le dossier sip_td_computer_git, puis ouvrez un nouveau terminal et faites de ce dossier votre répertoire de travail. En utilisant la commande shell appropriée (vous souvenez-vous de laquelle ?), vous devriez voir qu'un nouveau dossier, nommé .git, est là. Vous ne devez rien changer dans ce dossier, il est géré par Git.

• Avant de regarder la commande suivante, tapez git status dans le terminal. Un message vous informe que vous êtes dans la branche main (le nom de la branche courante est également affiché en bas à gauche de la fenêtre VS Code), qu'il n'y a pas de commits, et aucun fichier doit faire l'objet d'un commit.
  
  
• git switch -c main:
  La commande Git switch est utilisée pour changer la branche courante, l'option -c demande de créer la branche si elle n'existe pas. Comme nous sommes déjà dans la branche main, cette commande est inutile. Elle est donnée par GitLab car la branche par défaut s'appelait master dans les versions précédentes de GitLab. Il est maintenant d'usage de l'appeler main.
  
  
• touch README.md:
  La commande shell touch prend un nom de fichier en argument et met la date du jour comme date de modification du fichier ; si le fichier n'existe pas, il est créé. Cette commande est couramment utilisée sous Linux pour créer un fichier vide. Il est très important d'avoir un fichier README dans un dépôt Git. Lors des 'Coding Weeks', un README bien formaté et bien écrit influencera l'évaluation de la qualité de votre projet. Copiez cette commande touch, collez-la dans le terminal VS Code et exécutez-la.

• Saisissez à nouveau la commande git status. Un message devrait vous informer qu'il y a un fichier non suivi (Untracked file). Dans l'onglet Explorateur de VS Code, vous verrez la lettre U (qui signifie untracked) à droite du nom README.md. Passez votre curseur sur cette lettre U ; un message pop-up l'expliquera.
  
  
• git add README.md:
  cette commande demande à Git d'ajouter à l'index les fichiers donnés en argument. Ici, seul le fichier README.md est ajouté à l'index.
  • Tapez ou copiez/collez cette commande dans le terminal. Exécutez-la.
    
    
• Maintenant, git status vous informera que le fichier README.md sera validé lorsque la commande appropriée sera donnée. De plus, le U dans l'onglet Éxplorateur a été remplacé par un A (qui signifie added to index).
  
  
• git commit -m "Add README". Cette commande fait un commit d'une nouvelle version du projet dans la branche main de votre dépôt Git local. L'option -m est utilisée pour spécifier le commentaire associé au commit : ce commentaire est obligatoire, et vous devez écrire une phrase significative qui explique ce que la nouvelle version change par rapport à la précédente. Notez que les guillemets " sont nécessaires pour que le shell n'interprète pas Add et README comme deux arguments distincts ; l'argument de l'option -m est la phrase Add README :
  • Tapez ou copiez/collez cette commande dans le terminal. Exécutez-la. La lettre A dans l'onglet EXPLORER devrait disparaître.
    
    
• git push -u origin main : le but de cette commande est de transférer les modifications effectuées sur votre dépôt local (le nouveau README.md file) vers le dépôt distant sur GitLab. L'option -u indique à Git que la branche locale actuellement utilisée (la branche main dans notre cas) doit être associée à la branche portant le même nom sur le dépôt distant. Rien n'interdit d'utiliser des noms de branches différents ; mais une fois cette association décidée, la simple commande git push suffira. origin est le nom du dépôt distant (il a été défini par la commande Git clone), main est le nom de la branche qui sera transférée.
  • Tapez cette commande ou copiez/collez-la dans le terminal. Exécutez-la. Il vous sera demandé de donner votre Nom utilisateur en haut de la fenêtre VS Code et votre Mot de passe.
    
    

• Rafraîchissez la page web de GitLab : le fichier README.md devrait maintenant être visible, ainsi que le commit correspondant.
  
  
• En utilisant l'éditeur de VS Code, écrivez quelque chose dans le fichier README.md et sauvegardez-le. Une lettre M (Modifié) devrait apparaître dans l'onglet Explorateur. Dans la partie gauche de la fenêtre de VS Code, vous pouvez remarquer un ❶ au-dessus de l'icône de Contrôle de code source (vous l'avez probablement déjà remarqué avant). Cliquez sur cette icône pour passer à la vue "Contrôle de code source", puis cliquez sur le nom README.md : les différences entre la version actuelle du fichier README.md et la version dans le dépôt Git sont affichées.
  
  
• Vous pouvez utiliser l'icône ＋ pour ajouter les modifications à lindex, saisir un message et utiliser  ✓ Validation  pour valider, puis  Publier branch  pour publiser sur le dépôt distant.
  
  
• En utilisant le terminal de VS Code, ajoutez le fichier hello.py à votre dépôt git distant.
  
  

Vous avez appris l'utilisation de base de Git, c'est suffisant pour le moment. Vous en apprendrez plus durant les Coding Weeks. Si vous souhaitez en découvrir davantage par vous-même, nous vous recommandons ce livre électronique gratuit.