TP1 - Premiers pas avec Git

L'objectif de ce TP est de découvrir Git et faire ses premiers pas avec les commandes principales.

Partie 0 - Instructions

Sources à utiliser

Si vous ne trouvez pas, vous pouvez demander :

  1. À votre voisine ou voisin.
  2. À votre prof.
  3. À un moteur de recherche (DuckDuckGo par exemple).
  4. À StackOverflow.

Mais vous ne pouvez PAS utiliser un LLM (ChatGPT, DeepSeek, Gemini, Grok, etc). Sous aucun prétexte. Levez la main plutôt, et on viendra le plus vite possible.

Si on vous interdit d'utiliser ces outils dans ce cours, ce n'est pas parce qu'ils détruisent la planète, concentrent les pouvoirs dans les mains des Big Tech, mettent en danger les démocraties, etc.

C'est parce que ces outils vous empêchent d'apprendre correctement tout en vous donnant l'impression (rarement juste) de gagner du temps.

Si on voit un·e élève utiliser un LLM pendant un de nos TP, c'est -1 sur sa note finale. Non négociable. Mais cumulable.

Comment organiser son travail

Comment réaliser le TP

  • Suivre les instructions
  • Répondre aux questions dans un fichier appelé TP1.txt à rendre.
    • Lorsqu'il faut taper une commande pour obtenir la réponse, indiquez bien la commande.

Partie 1 - Explorer un repository Git existant

Une aventure palpitante

Adora, Bow et Catra, vos ami·es de toujours, ont choisi de rédiger leur rapport de R2.16 en Markdown en utilisant le logiciel de gestion de version Git, et tout allait pour le mieux jusqu'à ce qu'Adora vous appelle en panique : tout a disparu.

Vous n'y connaissez rien mais avez envie d'apprendre, alors vous acceptez de vous lancer dans une passionnante aventure à la découverte de Git, cet animal extraordinaire, dans le but d'aider votre amie.

Récupérer le code

Pour récupérer l'entièreté du code et de l'historique Git, il suffit d'une seule commande :

git clone https://framagit.org/ppom/rapport_r2_16

Cette commande crée le dossier rapport_r2_16.

Déplacez-vous dedans (avec la commande cd), puis listez les fichiers cachés (avec la commande ls -a).

Regardez, sans rentrer dedans, le contenu du dossier .git. À votre avis, que contient-il ?

Réponse

Il contient énormément d'information dont le fameux historique des modifications, des copies des différentes versions des fichiers, etc.

⚠️ Il est très risqué de manipuler directement le fichier .git, mieux vaut toujours utiliser les commandes qui permettent de le modifier. On n'y touche jamais sauf si on sait exactement ce qu'on fait.

Exploration du dépôt

On voit qu'il n'y a qu'un seul fichier, readme.md, qui ne contient pas le rapport sur le rat-taupe nu. On va commencer par regarder l'historique pour essayer de comprendre ce qu'il s'est passé.

  • Quelle est la commande permettant d'afficher l'historique ?
  • Qui a effectué la dernière modification ?
  • Qui a effecuté la modification d'avant ?
  • Quel est l'identifiant du dernier commit ?
  • Affichez le contenu de ce commit, c'est-à-dire l'ensemble des modifications qui ont été effecutées.

L'argument --word-diff permet de visualiser les différences non pas entre les lignes, comme c'est le comportement par défaut, mais entre les mots au sein d'un même ligne.

Dans notre cas, la seule ligne du fichier a été modifiée, ce qui n'est pas très pratique pour voir rapidement ce que change le commit. Essayez la commande précédante avec --word-diff pour voir directement les mots changés.

  • S'agit-il du commit qui a fait disparaître le rapport ?

  • Explorez, à l'aide des commandes git log, git diff, et/ou git show, l'historique du dépôt pour trouver le commit fautif.

  • Décrivez l'ensemble des modifications effectuées depuis le commit d'avant le commit fautif ?

  • Déplacez vous à l'état du commit d'avant le commit fautif.

  • Est-ce qu'on peut repartir de ce commit pour remodifier la licence en GPLv3 ?

Réponse

Non. Enfin techniquement on peut, mais il ne faut pas le faire !

Si on fait un git log --all --graph, qui permet d'afficher tout l'historique dans l'ordre, on constate que si on fait un commit à partir d'ici, on va avoir une divergence. Or, on ne doit jamais (sauf dans certains cas précis qu'on verra plus tard) réécrire l'historique. On verra également plus tard comment gérer les divergences, mais pour l'instant on évite : ce qui est fait est fait, l'historique est immuable.

  • On se redéplace au dernier commit, celui de Catra qui modifie la licence.

On pourrait le faire de la même façon que ce que l'on vient de faire, en récupérant son identifiant et en utilisant git switch -d. Cependant, le -d veut dire « détaché », c'est à dire qu'il permet d'explorer mais on ne peut pas faire de modifications après. On verra la semaine prochaine en détail, mais si on fait git log --all --graph on observe plusieurs choses à côté de l'identifiant : main, origin/main et origin/HEAD. Il s'agit de de noms de « branche » à partir desquelles ont peut continuer les modifications. Ainsi, git switch main est dans notre cas presque équivalent à git switch -d 351f, mais nous permet d'effectuer de nouveaux commits.

On a donc trouvé le commit fautif. Mais on ne peut pas repartir de lui puisque ça impliquerait de modifier l'historique, et on ne peut pas changer le passé. Dommage pour la personne coupable, sa culpabilité restera gravée dans le marbre à jamais. Mais on a quand même besoin d'annuler ce commit, sans modifier l'historique.

  • Cherchez sur un moteur de recherche (genre Duckduckgo) comment révoquer un commit avec git. Ne lancez pas encore la commande ! Elle va ajouter un commit à l'historique, il faut donc configurer votre identité avant, pour qu'elle puisse s'enregistrer correctement.

Configurer son identité dans Git

C'est votre nom et votre mail, tels qu'ils apparaitront dans vos commits.

Tapez les commandes suivantes :

$ git config --global user.name "<PRENOM> <NOM>"
$ git config --global user.email "<MAIL_IUT>"

⚠️ Dans tous les exemples de code, un mot écrit comme ça : <MOT> doit être remplacé. Il ne doit pas être écrit tel quel 🫩

De la même manière, un $ en début de ligne symbolise le prompt, par exemple ppompeani@b110-02:~$. Il ne faut pas l'écrire 🫩🫩

Dans l'exemple précédent, René Coty tape dans son terminal :

git config --global user.name "René Coty"
git config --global user.email "rene.coty@elysee.fr"
  • Vous pouvez maintenant lancer la commande. Vérifiez que les deux fichiers contiennent bien ce que vous voulez.

Eh voilà, vous avez résolu le problème d'Adora, et nos trois ami·es vont pouvoir rendre leur projet sans soucis ! Vous pouvez maintenant passer à la deuxième partie du TP et créer votre propre dépôt !

⚠️ Pensez à sortir du dossier rapport_r2_16 avant de continuer le TP d'ailleurs.

Partie 2 - Créer son propre repository Git

Dans cette partie, on ne va plus se contenter d'étudier un historique Git existant : on va créer notre propre repository et y construire pas à pas un historique.

Créer son repository

La commande git init permet d'initialiser un repo dans un dossier existant.

Créer un dossier (avec mkdir <NOM_DOSSIER>), se déplacer dedans, puis lancer la commande git init.

Q° 2.a. Est-ce que le dossier est toujours vide ?

Lancer la commande git status.

Q° 2.b. Qu'est-ce qu'elle nous dit ?

Premier fichier

Créer un fichier appelé chat.txt, et écrire dedans une histoire en une phrase sur un chat. Vous donnerez le nom de votre choix au chat.

Lancer git status.

Q° 2.c. Que nous dit la commande ? Dans quel espace est le fichier chat.txt ? Quelle commande est suggérée ?

Ajout à la staging area

Ajouter le fichier à la staging area.

Vérifier que le fichier a bien été "ajouté" pour le prochain commit avec git status.

Q° 2.d. Lancer la commande qui permet de consulter l'historique des commits. Est-ce qu'un commit a été créé ?

Premier commit

Créez un commit.

On remarque qu'un éditeur de texte s'ouvre : c'est vim. Si vous ne l'avez toujours pas utilisé, voici les bases :

  • tous les raccourcis que vous connaissez ne marchent pas. Ils font autre chose. (Ctrl-C, Ctrl-V, Ctrl-Z... oubliez.)
  • en gros vim a deux modes : commande et édition.
  • quand on ouvre vim, on est dans le mode commande.
  • dans le mode commande, chaque caractère tapé fait une opération spéciale.
  • dans le mode insertion, chaque caractère tapé est inséré.
  • on va du mode commande au mode insertion avec le caractère : i (entre autres... 🤓)
  • on va du mode insertion au mode commande avec la touche Echap.
  • le mode commande est obscur, mais c'est lui qui fait la 🔥 puissance 🔥 de vim.
  • une cheatsheet si vous voulez découvrir plus de commandes.
  • pour sauvegarder et quitter, on tape depuis le mode commande : :wq puis Entrée.
  • pour sauvegarder sans quitter, on tape depuis le mode commande : :q! puis Entrée.

En résumé :

  • i quand vim s'ouvre.
  • Echap, :wq, Entrée, pour quitter

Écrire sur une ligne un message court qui décrit ce qui a été fait. Exemple : Ajout histoire du chat. Sauvegarder et quitter.

Q° 2.e. Lancer git status et git log. Est-ce qu'un commit a été créé ? Est-ce qu'il y a des modifications non enregistrées ?

Deuxième modification

Éditer à nouveau chat.txt et ajouter une phrase sur une nouvelle ligne.

Éditer un nouveau fichier hamster.txt avec le nom d'un hamster.

Lancer git status.

Q° 2.e. Quelle est la différence entre les deux fichiers dans Git ?

Ajout / retrait

Ajouter les deux fichiers à la staging area.

Lancer git status.

On change d'avis : dans notre prochain commit, on ne veut plus commit hamster.txt. On veut seulement commit les modifications de chat.txt.

Retirer le fichier hamster.txt de la staging area.

Q° 2.f. Quelles commandes avez-vous entrées pour le faire ?

Afficher un commit

Deuxième commit

Lancer git status pour vérifier qu'on s'apprête bien à commit seulement chat.txt, puis créer le commit.

Une fois le commit réalisé, lancer git log pour vérifier qu'on a bien un 2e commit.

Q° 2.g. Quelle commande lancer pour afficher le dernier commit réalisé ?

Troisième commit

Ajouter le fichier hamster et créer un commit.

Q° 2.h. Quelles commandes avez-vous entrées pour le faire ? Copier dans le fichier de réponses le résultat de git log.