Suivre une première modification

Ce que vous saurez faire

Enregistrez votre travail en petites étapes nommées et voyez exactement ce qui a changé à chaque étape. C’est votre principale activité quotidienne avec Git.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 30 minutes

Ce que vous devez savoir

• Ce qu’est un dépôt, expliqué dans Configurer Git : un dépôt est un dossier avec un historique.
• Ce que montre git status, expliqué dans Configurer Git : Étape 3 : créer un dépôt.

Ce qu’il vous faut sur votre ordinateur

• Git, avec votre nom et votre adresse courriel. Vous les avez définis dans Configurer Git : Étape 2 : indiquer votre identité à Git. Pour les vérifier, exécutez git config --global --list.

• Le dépôt vide ~/projects/ticket-notes. Vous l’avez créé dans Configurer Git : Étape 3 : créer un dépôt. Dans ce dépôt, git status affiche No commits yet (aucun commit pour le moment). Si le dossier manque, refaites cette étape.

• Si le dépôt manque ou ne fonctionne plus, un script peut recréer l’état de départ de cette leçon. Dans ~/projects, exécutez :

  git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git
  sh nextia-learning-labs/C14/setup.sh m01-l03 --reset

  Exécutez la commande git clone une seule fois. Si vous avez déjà le dossier nextia-learning-labs, exécutez plutôt git -C nextia-learning-labs pull. Les étapes d’une demande de tirage : préparer le laboratoire d’exercice explique le script en détail. Le script crée ~/projects/c14-lab/ticket-notes : un dépôt vide sur main, sans commits ni dépôt distant. Utilisez ensuite ~/projects/c14-lab à la place de ~/projects dans cette leçon. --reset supprime d’abord tout ancien dossier c14-lab, mais ne modifie pas votre dossier ~/projects/ticket-notes.

• Un éditeur de texte, par exemple Visual Studio Code. Tout éditeur qui enregistre du texte brut convient. Pour ouvrir un terminal dans votre éditeur, consultez Premiers pas dans le terminal : ouvrir un terminal depuis votre éditeur.

Trois endroits pour vos modifications

Git n’enregistre pas automatiquement chaque modification. Vous choisissez quoi enregistrer et quand. Pour cela, Git garde vos modifications à trois endroits :

1. L’arbre de travail contient les fichiers de votre dossier de projet, tels que vous les voyez dans votre éditeur. Quand vous modifiez un fichier, vous modifiez l’arbre de travail.
2. La zone de préparation contient la liste des modifications à inclure dans votre prochain enregistrement. Vous y placez une modification avec git add.
3. L’historique des commits contient la liste des étapes enregistrées. Vous enregistrez la zone de préparation comme nouvelle étape avec git commit.

Un commit est une étape enregistrée. C’est un instantané du projet, accompagné d’un message qui explique pourquoi vous avez fait la modification. Git enregistre aussi l’auteur, la date et un identifiant pour le commit.

Une modification passe de l'arbre de travail à la zone de préparation avec git add, puis dans l'historique avec git commit.

Pourquoi avoir une zone de préparation? Elle vous laisse choisir. Vous pouvez modifier cinq fichiers, puis en enregistrer deux dans un commit et trois dans un autre. Chaque commit contient alors une modification claire, plus facile à réviser et à annuler.

Exemple détaillé : le premier commit d’Amira

Amira est dans ~/projects/ticket-notes. Elle crée un fichier nommé README.md dans son éditeur, avec ce texte :

README.md

# Ticket notes

Notes about support tickets.

Elle enregistre le fichier et demande à Git l’état du dépôt :

Terminal

git status

Sortie

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
  README.md

nothing added to commit but untracked files present (use "git add" to track)

README.md est non suivi : il est dans l’arbre de travail, mais Git ne le suit pas encore. Elle l’ajoute à la zone de préparation et vérifie à nouveau :

Terminal

git add README.md
git status

Sortie

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
  new file:   README.md

Le fichier apparaît maintenant sous « Changes to be committed » (modifications à inclure dans le prochain commit). C’est la zone de préparation. Ensuite, elle l’enregistre dans un commit. L’option -m fournit le message :

Terminal

git commit -m "Add README"

Sortie

[main (root-commit) 763ec59] Add README
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

La sortie montre la branche (main), un identifiant court (763ec59) et le message. root-commit (commit initial) signifie qu’il s’agit du premier commit du dépôt. Pour voir l’historique, elle exécute git log :

Terminal

git log

Sortie

commit 763ec59e42a90d5d11f064bc677d31b91bfc4e39 (HEAD -> main)
Author: Amira Khan <amira@example.com>
Date:   Mon Oct 5 20:31:22 2026 -0400

    Add README

Le long texte après commit est l’empreinte du commit : un identifiant que Git calcule à partir du contenu du commit. Deux commits n’ont jamais la même empreinte. Git affiche habituellement seulement les sept premiers caractères, par exemple 763ec59. Votre empreinte est différente, car l’auteur et l’heure de votre commit sont différents.

Exemple détaillé : voir une modification avant de l’enregistrer

Amira remplace la dernière ligne de README.md par Notes about support tickets for the help desk. (notes sur les billets d’assistance du centre de soutien). Elle crée aussi un fichier, tickets.txt :

tickets.txt

Ticket 101: printer offline. Restarted the spooler.

Elle a maintenant deux modifications. Pour voir un bref résumé, elle utilise git status --short :

Terminal

git status --short

Sortie

 M README.md
?? tickets.txt

Pour voir la modification exacte dans README.md, elle utilise git diff. Un diff (comparaison des différences) montre les lignes modifiées :

Terminal

git diff

Sortie

diff --git a/README.md b/README.md
index 8f872d3..a30ec45 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
 # Ticket notes

-Notes about support tickets.
+Notes about support tickets for the help desk.

Voici comment lire un diff :

• Une ligne qui commence par - a été supprimée. Une ligne qui commence par + a été ajoutée. Une ligne modifiée apparaît sous ces deux formes.
• Les lignes sans signe n’ont pas changé. Git les montre pour vous aider à situer la modification.
• @@ -1,3 +1,3 @@ donne les numéros de ligne : lignes 1 à 3 dans l’ancien fichier et dans le nouveau fichier.

git diff ne montre pas tickets.txt, car Git ne suit pas encore ce fichier. git diff compare seulement les fichiers suivis.

Amira veut deux commits : un pour la modification du README et un pour le billet. Elle place seulement le README dans la zone de préparation :

Terminal

git add README.md
git status --short

Sortie

M  README.md
?? tickets.txt

Le M est passé de la deuxième colonne à la première. Ces deux colonnes sont la partie la plus utile de git status --short :

Code	Première colonne : zone de préparation	Deuxième colonne : arbre de travail
M	La modification est dans la zone de préparation. Elle sera incluse dans le prochain commit.	Aucune autre modification.
M	Rien n’est dans la zone de préparation.	Le fichier a changé, et la modification n’est pas dans la zone de préparation.
MM	Une modification est dans la zone de préparation.	Le fichier a encore changé après son ajout à la zone de préparation.
??	Le fichier est non suivi.	Le fichier est non suivi.
A	Un nouveau fichier est dans la zone de préparation.	Aucune autre modification.

git diff montre seulement les modifications hors de la zone de préparation. La modification du README est maintenant dans cette zone. Amira utilise donc git diff --staged pour voir le contenu du prochain commit. La sortie montre le même diff qu’avant. Ensuite, elle crée deux commits :

Terminal

git commit -m "Describe who the notes are for"
git add tickets.txt
git commit -m "Add first ticket note"
git log --oneline

Sortie

d8ae027 (HEAD -> main) Add first ticket note
49397ba Describe who the notes are for
763ec59 Add README

git log --oneline montre un commit par ligne, du plus récent au plus ancien. (HEAD -> main) indique le commit où vous vous trouvez maintenant. Vous apprendrez ce que cela signifie dans le prochain module.

Remarque

Le message d’un commit n’est pas la modification. Le message est ce que l’auteur dit d’une modification. L’empreinte identifie la modification elle-même. Avant de vous fier à un message, regardez la modification : git show 49397ba montre le message et le diff complet de ce commit.

Exercice guidé : créer vos premiers commits

Reproduisez l’exemple détaillé dans votre propre dépôt ticket-notes. Après chaque commande, comparez votre sortie à celle d’Amira.

1. Vérifiez que vous êtes dans le dépôt :

   cd ~/projects/ticket-notes
   git status

   La sortie affiche No commits yet.

2. Dans votre éditeur, créez README.md avec les trois lignes du premier exemple détaillé. Enregistrez le fichier.

3. Exécutez git status. README.md apparaît sous « Untracked files » (fichiers non suivis).

4. Placez le fichier dans la zone de préparation :

   git add README.md

5. Exécutez git status. README.md apparaît sous « Changes to be committed ».

6. Enregistrez-le dans un commit :

   git commit -m "Add README"

   La sortie commence par [main (root-commit).

7. Exécutez git log --oneline. La sortie montre un commit.

8. Modifiez la dernière ligne de README.md et créez tickets.txt avec une note sur un billet. Enregistrez les deux fichiers.

9. Exécutez git status --short. La sortie affiche M README.md et ?? tickets.txt.

10. Exécutez git diff. La sortie montre une ligne - et une ligne +.

11. Placez la modification du README dans la zone de préparation et enregistrez-la dans un commit :

    git add README.md
    git commit -m "Describe who the notes are for"

12. Placez la note sur le billet dans la zone de préparation et enregistrez-la dans un commit :

    git add tickets.txt
    git commit -m "Add first ticket note"

13. Exécutez git log --oneline. La sortie montre trois commits. Exécutez git status. La sortie indique nothing to commit, working tree clean (rien à enregistrer, arbre de travail propre).

À vous : deux commits, puis examinez-les

Créez deux autres commits (enregistrements de modifications) dans ticket-notes, un pour chaque changement :

1. Ajoutez une deuxième note de billet à tickets.txt.
2. Ajoutez un nouveau fichier, contacts.txt, avec le nom d’une équipe de soutien technique.

Ensuite, pour chacun de vos deux nouveaux commits, utilisez git show --stat pour voir quels fichiers il a modifiés. Trouvez les empreintes courtes avec git log --oneline, et utilisez les vôtres au lieu de d8ae027 :

git show --stat d8ae027

Sortie (fin)

 tickets.txt | 1 +
 1 file changed, 1 insertion(+)

Chacun de vos commits doit modifier un seul fichier. Si un commit a modifié les deux fichiers, vous les avez tous deux préparés avant de créer le commit. Vous apprendrez à annuler un commit au module 4. Pour l’instant, modifiez encore une fois chaque fichier, puis créez un commit distinct pour chacun.

Erreur courante

Git ouvre un éditeur inhabituel

Symptôme : vous exécutez git commit sans -m. Le terminal affiche un écran de texte, et les touches ne réagissent pas comme prévu. La ligne du bas peut afficher des caractères ~, ou le nom d’un éditeur comme Vim ou nano.

Cause : Git a besoin d’un message de commit. Si vous n’en fournissez pas avec -m, Git ouvre un éditeur de texte pour vous permettre de le saisir. Sur de nombreux systèmes, l’éditeur par défaut est Vim, qui fonctionne différemment des autres éditeurs.

Solution : quittez l’éditeur sans enregistrer. Git annule alors le commit.

1. Dans Vim : appuyez sur Esc (Échap), tapez :q!, puis appuyez sur Enter (Entrée).
2. Dans nano : appuyez sur Ctrl+X. Si nano demande d’enregistrer, appuyez sur N.

Git affiche Aborting commit due to empty commit message. (commit annulé parce que le message est vide). Vos modifications préparées restent dans la zone de préparation. Exécutez de nouveau la commande de commit avec -m "your message".

Erreur courante

Rien à ajouter au commit

Symptôme : vous exécutez git commit -m "Add ticket", et Git affiche nothing added to commit but untracked files present (rien à ajouter au commit, mais des fichiers non suivis sont présents), ou no changes added to commit (aucune modification ajoutée au commit).

Cause : la zone de préparation est vide. Vous avez modifié des fichiers, mais vous n’avez pas exécuté git add. Git n’a donc rien à enregistrer.

Solution : exécutez git status pour voir vos modifications. Exécutez git add pour chaque fichier à inclure dans le commit. Puis créez de nouveau le commit.

Vérifiez votre compréhension

Faites une prédiction : Amira prépare tickets.txt avec git add. Puis elle ajoute une autre ligne à tickets.txt et l'enregistre. Qu'affiche git status --short? Que contiendra son prochain commit?

Afficher la réponse

La commande affiche MM tickets.txt. Le premier M indique la modification préparée. Le deuxième M indique la modification plus récente dans l’arbre de travail, qui n’est pas préparée. Le prochain commit contient seulement la version préparée : le fichier tel qu’il était quand elle a exécuté git add. Pour inclure la nouvelle ligne, elle doit exécuter git add tickets.txt de nouveau.

Vérifiez votre compréhension

Vérification pratique : pour chaque fichier de cette sortie de git status --short, indiquez si sa modification est non préparée, préparée ou non suivie : 'M README.md', ' M contacts.txt', '?? notes.txt'.

Afficher la réponse

• README.md : préparée. Le M est dans la première colonne. La modification sera incluse dans le prochain commit.
• contacts.txt : non préparée. Le M est dans la deuxième colonne. Git suit le fichier, mais cette modification n’est pas dans la zone de préparation.
• notes.txt : non suivie. Git ne suit pas encore ce fichier.

Une modification déjà enregistrée dans un commit n’apparaît pas dans git status. Vous la voyez avec git log et git show.

Récapitulatif

• Les modifications passent de l’arbre de travail à la zone de préparation avec git add, puis à l’historique des commits avec git commit.
• git status et git status --short montrent où se trouve chaque modification. git diff montre les modifications non préparées, et git diff --staged montre les modifications préparées.
• Une empreinte de commit identifie un commit. git show <hash> montre ce que le commit a réellement modifié.
• Préparez seulement les modifications qui vont ensemble, pour que chaque commit représente une étape claire.

C’est la fin du module 1. Au module 2, vous travaillez sur une ligne distincte de modifications avec des branches. Vous partagez aussi votre travail avec un dépôt distant.