Historique et modifications

Introduction

Dans les labs précédents, vous avez appris à initialiser une « machine à remonter le temps » (un dépôt Git) et à enregistrer votre premier instantané. Mais un projet n’est pas statique : il évolue. Vous corrigez des bugs, ajoutez des fonctionnalités et mettez à jour la documentation.

Git est particulièrement adapté au suivi de cette évolution. Il vous permet de :

Inspecter les modifications : voir exactement quelles lignes vous avez modifiées avant de les enregistrer.
Consulter l’historique : revoir chaque instantané enregistré afin de savoir qui a fait quoi et quand.

C’est là toute la valeur du contrôle de version : il ne sert pas seulement à conserver des sauvegardes, mais aussi à préserver un historique structuré de l’évolution d’un projet.

Dans ce lab, vous allez modifier un fichier, examiner précisément les différences avec git diff, enregistrer un nouvel instantané, puis parcourir l’historique du projet avec git log. Cette boucle de vérification constitue la base des workflows Git utilisés au quotidien.

Modifier un fichier du projet

Nous partons d’un dépôt qui contient déjà un commit (le « commit initial »). Simulons maintenant une modification de ce projet.

Accédez au répertoire du projet :

cd /home/labex/project

Affichez le contenu actuel de readme.txt :

cat readme.txt

Vous devez voir : Hello World

Modifiez le fichier en ajoutant une nouvelle ligne à la fin. Nous allons ajouter une description simple :

echo "Git is a version control system" >> readme.txt

Vérifiez que le fichier a bien été modifié :

cat readme.txt

Résultat :

Hello World
Git is a version control system

Git a détecté que readme.txt est différent de la version stockée dans le dernier instantané. Le fichier est désormais considéré comme Modified.

Examiner les modifications avec Git Diff

Avant d’enregistrer votre travail, il est recommandé de vérifier précisément ce que vous avez modifié. C’est comparable à la relecture d’un devoir avant de le remettre.

Git fournit la commande diff à cet effet. Elle compare le fichier présent dans votre répertoire de travail avec le fichier du dernier commit (instantané).

Ainsi, git diff compare deux états : ce qui est enregistré dans l’historique et ce qui existe actuellement dans votre arborescence de travail. C’est l’un des principaux outils permettant de vérifier votre travail avant de l’enregistrer définitivement.

Exécutez git diff pour afficher les modifications :

git diff

Analysez la sortie :

diff --git a/readme.txt b/readme.txt
index ...
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,2 @@
 Hello World
+Git is a version control system

--- a/readme.txt : la version d’origine (ancienne).
+++ b/readme.txt : la version actuelle (nouvelle).
+Git is... : le signe plus (+) indique une ligne nouvellement ajoutée. (Un signe moins - indiquerait une ligne supprimée.)

Savoir lire la sortie de diff est une compétence essentielle avec Git, car elle affiche les modifications ligne par ligne. De nombreux workflows ultérieurs, comme la revue de code, l’application de correctifs et les pull requests, reposent sur le même principe.

Cette étape confirme que vos modifications correspondent exactement à ce que vous vouliez faire.

Enregistrer les modifications avec Git Commit

Maintenant que vous avez vérifié les modifications, enregistrez un nouvel instantané. Souvenez-vous du processus en deux étapes : Stage (placer le fichier sur le quai de chargement), puis Commit (prendre l’instantané).

Vérifiez d’abord l’état du dépôt :

git status

Vous verrez readme.txt en rouge sous « Changes not staged for commit ».

Placez le fichier dans la zone de staging :

git add readme.txt

Vérifiez de nouveau l’état du dépôt :

git status

readme.txt apparaît maintenant en vert sous « Changes to be committed ».

C’est un autre exemple de la séparation opérée par Git entre le contenu modifié et le contenu placé dans la zone de staging. Une modification peut exister dans votre fichier, mais tant que vous ne l’avez pas ajoutée à la zone de staging, elle ne fait pas partie du prochain commit prévu.

Enregistrez l’instantané avec un message explicite :

git commit -m "Add description about Git"

-m : permet de saisir immédiatement le message du commit.
Le message doit indiquer ce que vous avez modifié.

Vous venez d’enregistrer la deuxième version de l’historique de votre projet !

Consulter l’historique du projet

Votre dépôt contient maintenant deux commits. Pour afficher la chronologie de votre projet, utilisez la commande git log. C’est votre « livre d’historique ».

Affichez l’historique complet :

git log

Examinez la sortie :

commit 8d3a1b2... (SHA Hash)
Author: Your Name <you@example.com>
Date:   Mon Oct 10 10:00:00 2023 +0000

    Add description about Git

commit 4f2b3c4... (SHA Hash)
Author: Your Name <you@example.com>
Date:   Mon Oct 10 09:00:00 2023 +0000

    Initial commit

SHA Hash : la longue chaîne d’identification (par exemple, 8d3a...). Il s’agit de l’empreinte unique de cet instantané précis.
HEAD : (s’il est visible) un pointeur indiquant votre position actuelle.
Ordre : le commit le plus récent apparaît toujours en haut.

Ces hachages sont essentiels pour permettre à Git d’identifier l’historique. Au lieu de nommer les commits avec des numéros séquentiels, Git utilise des identifiants fondés sur le contenu, afin que chaque instantané possède une référence unique.

(Appuyez sur q pour quitter l’affichage de l’historique si nécessaire.)

Afficher un historique condensé

Lorsque vous travaillez sur un projet pendant plusieurs mois, la sortie complète de git log peut devenir trop longue et trop détaillée. Vous pouvez parfois avoir besoin uniquement d’une liste récapitulative rapide.

Git propose l’option --oneline à cet effet.

Exécutez la commande d’affichage condensé de l’historique :

git log --oneline

Vérifiez la sortie :

8d3a1b2 Add description about Git
4f2b3c4 Initial commit

Cette vue affiche uniquement le hachage court et le message du commit, un par ligne. Elle est idéale pour parcourir rapidement les événements récents.

Défi :

Modifiez encore une fois readme.txt (ajoutez une nouvelle ligne), validez la modification, puis exécutez de nouveau git log --oneline. Vous devez voir trois entrées !

Résumé

Dans ce lab, vous avez appris à gérer le cycle de vie des modifications d’un projet :

Modifier : vous avez modifié un fichier.
Inspecter : vous avez utilisé git diff pour vérifier ces modifications.
Valider : vous avez enregistré un instantané permanent avec git add et git commit.
Vérifier : vous avez exploré la chronologie avec git log et git log --oneline.

Ces quatre commandes sont au cœur de l’utilisation quotidienne de Git. Maîtrisez-les pour maîtriser les bases du contrôle de version.