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.
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 statusLa 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 --cachedAprè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.mdLa 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.mdLe 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
- Lire status pour connaître tous les fichiers concernés.
- Lire le diff et vérifier le comportement attendu.
- Préparer seulement le changement cohérent à enregistrer.
- Lire le diff préparé, y compris les suppressions.
- Créer un message qui décrit l’intention.
- 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.