Enregistrer des commits propres

Page 3 sur 10. Maîtriser le dossier de travail, l’index, les différences et l’historique.

1. Les trois espaces à distinguer

Le dossier de travail contient votre version actuelle des fichiers. L’index, aussi appelé zone de préparation, décrit le contenu du prochain commit. Le dépôt local contient les commits déjà enregistrés. On peut donc modifier un fichier sans préparer cette modification, puis en préparer une partie sans avoir encore créé de commit.

git add place la version choisie dans l’index. Si vous modifiez à nouveau le même fichier après add, ces nouvelles modifications ne sont pas automatiquement incluses. Un fichier peut alors avoir une modification préparée et une autre non préparée.

Add sélectionne une version pour l’index ; commit enregistre cet index. Restore sans source restaure le fichier depuis l’index ; restore --staged utilise par défaut HEAD.
Add sélectionne une version pour l’index ; commit enregistre cet index. Restore sans source restaure le fichier depuis l’index ; restore --staged utilise par défaut HEAD. Cliquer pour agrandir.

2. Préparer et enregistrer le premier instantané

git add README.md index.html .gitignore .gitattributes
git diff --cached
git commit -m "Créer la base du portail NKILItech"
git status

La liste explicite des fichiers montre ce que l’on sélectionne. git diff --cached affiche la différence entre l’index et le commit courant ; avant le premier commit, il montre le contenu préparé pour la création initiale. La commande commit enregistre l’index, puis status permet de vérifier ce qui reste.

Un message commence par l’intention du changement : « Ajouter le formulaire de demande » est plus utile que « modification » ou « final ». Un commit doit former une étape cohérente et relisible. Il n’est pas nécessaire de créer un commit pour chaque frappe ni d’attendre plusieurs jours pour tout mélanger.

3. Lire status et comparer les bonnes versions

Add-Content -Encoding utf8 README.md "Portail de suivi des demandes clients."
git diff
git add README.md
git diff --cached
Add-Content -Encoding utf8 README.md "Version pédagogique."
git status --short
git diff
git diff --cached

Après la seconde modification, MM README.md peut apparaître : la première colonne représente l’index et la seconde le dossier de travail. git diff montre ce qui diffère entre dossier de travail et index. git diff --cached montre ce qui est déjà préparé par rapport à HEAD.

Si les deux phrases appartiennent au même changement, relancez add sur README.md, vérifiez le diff préparé puis créez le commit. Si la seconde phrase doit attendre, vous pouvez conserver cette modification hors de l’index.

git add README.md
git diff --cached
git commit -m "Documenter le rôle du portail"

4. Sélection fine, suppressions et déplacements

git add -p propose une sélection par blocs de changements. Il permet par exemple de séparer une correction de texte d’un changement fonctionnel dans le même fichier. Chaque bloc préparé doit rester compréhensible avec le reste du commit.

git add -p README.md
git diff --cached
git restore --staged README.md

La dernière commande retire les changements de l’index en prenant HEAD comme référence, tout en conservant le fichier modifié dans le dossier de travail. Elle suppose qu’un premier commit existe, comme dans ce laboratoire.

git add -A prend en compte ajouts, modifications et suppressions dans son périmètre ; relisez donc le résultat avant de commiter. Git peut reconnaître un renommage en comparant les contenus : un renommage n’est pas une opération magique indépendante de la modification des fichiers. Les dossiers vides ne sont pas suivis comme tels.

5. Explorer l’historique

git log --oneline --decorate --graph --all
git log -- README.md
git show HEAD
git show HEAD:README.md
git diff HEAD~1 HEAD -- README.md

Le graphe rend visibles les branches et les liens entre commits. L’option -- sépare les révisions des chemins. git show HEAD:README.md lit la version enregistrée sans modifier le fichier courant. La dernière commande compare les deux derniers commits ; elle nécessite donc au moins deux commits.

Dans un diff, les lignes précédées de moins appartiennent à l’ancienne version ; les lignes précédées de plus appartiennent à la nouvelle. Les marques du diff ne sont pas des caractères à recopier dans votre fichier.

6. La routine avant chaque commit

  1. Lire status pour connaître tous les fichiers concernés.
  2. Lire le diff et vérifier le comportement attendu.
  3. Préparer seulement le changement cohérent à enregistrer.
  4. Lire le diff préparé, y compris les suppressions.
  5. Créer un message qui décrit l’intention.
  6. Relire status pour savoir ce qui reste localement.

Cette routine est courte et répétable. Elle réduit notamment les commits contenant un fichier temporaire, un mot de passe ou une modification sans rapport. Le dépôt gagne en clarté parce que chaque étape devient vérifiable.

Exercices corrigés

Exercice 1 - Deux versions d’un fichier

Vous faites add, modifiez encore le fichier puis commit. Quelle version est enregistrée ?

Voir le corrigé détaillé

La version préparée au moment du add, sauf nouvelle préparation. Le deuxième changement reste local et non préparé. Vérifiez avec diff et diff --cached.

Exercice 2 - Retirer une préparation

Comment conserver le texte modifié tout en le retirant du prochain commit ?

Voir le corrigé détaillé

Après un premier commit, git restore --staged chemin remet l’index à HEAD pour le chemin concerné. Le contenu modifié du dossier de travail est conservé.

Exercice 3 - Écrire un message

Remplacer le message final v2 par une intention utile pour une page de contact.

Voir le corrigé détaillé

Par exemple : Ajouter la page de contact client. Le message exprime un changement concret ; les détails utiles peuvent être ajoutés dans un corps de message.

Avant de passer à la suite

Je sais expliquer la différence entre diff et diff --cached et sélectionner mon prochain commit.

Pour approfondir

Sources officielles consultées pour ce chapitre : Enregistrer les changements, git diff. Cours et schémas originaux ; exemples NKILItech pédagogiques. Vérification documentaire : 28 octobre 2026.