Enregistrer des modifications avec Git : add, commit, status

Ce guide vous apprend à enregistrer vos modifications dans Git étape par étape. Vous allez maîtriser le cycle quotidien de tout utilisateur Git : vérifier l'état de vos fichiers (status), préparer vos modifications (add), inspecter les différences (diff) et créer un commit. Vous apprendrez aussi à exclure les fichiers indésirables avec .gitignore.

Prérequis : un dépôt Git initialisé. Avoir compris les 3 états de Git (Working Directory, Staging Area, Repository).

Ce que vous allez apprendre

• Le cycle de vie des fichiers : non suivi → non modifié → modifié → indexé
• git status : voir l'état de chaque fichier
• git add : placer des modifications dans la Staging Area
• git diff : inspecter ce qui a changé
• git commit : enregistrer un snapshot dans l'historique
• .gitignore : exclure les fichiers qui ne doivent pas être versionnés

Le cycle de vie des fichiers

Chaque fichier de votre projet est dans l'un de ces 4 états :

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Un fichier non suivi (untracked) est un fichier que Git ne connaît pas encore. Dès que vous l'ajoutez avec git add, Git commence à le suivre. Après un commit, le fichier redevient non modifié jusqu'à votre prochaine modification.

Vérifier l'état avec git status

C'est la commande que vous utiliserez le plus souvent. Elle vous montre exactement dans quel état se trouvent vos fichiers.

git status

Sortie attendue (dépôt avec des fichiers dans différents états) :

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   index.html

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   style.css

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

Cette sortie vous indique trois choses :

• index.html est dans la Staging Area, prêt à être committé
• style.css est modifié mais pas encore indexé
• script.js est non suivi, Git ne le connaît pas encore

Version courte

Pour un résumé compact, utilisez git status -s (short) :

git status -s

A  index.html
 M style.css
?? script.js

Les colonnes indiquent : colonne gauche = Staging, colonne droite = Working Directory. A = ajouté, M = modifié, ?? = non suivi.

Indexer des fichiers avec git add

La commande git add déplace des fichiers du Working Directory vers la Staging Area. C'est l'étape de sélection : vous choisissez exactement quelles modifications inclure dans votre prochain commit.

Ajouter un fichier spécifique

Nommer explicitement le fichier est la méthode la plus sûre : vous indexez exactement ce que vous voulez, rien de plus. C'est le réflexe à privilégier quand votre répertoire contient des modifications en cours que vous n'êtes pas encore prêt à committer.

git add index.html

Ajouter plusieurs fichiers

Vous pouvez enchaîner plusieurs noms sur la même ligne. Git les indexe tous en une passe, ce qui reste préférable à git add . tant que vous maîtrisez la liste : vous gardez le contrôle sur ce qui entre dans le commit.

git add index.html style.css script.js

Ajouter tous les fichiers modifiés et non suivis

git add .

Cette commande ajoute tout le contenu du répertoire courant et de ses sous-répertoires. C'est pratique, mais vérifiez d'abord avec git status que vous ne risquez pas d'indexer des fichiers indésirables.

Attention à git add .

git add . ajoute tout : fichiers modifiés, nouveaux fichiers, fichiers supprimés. Assurez-vous d'avoir un .gitignore bien configuré avant de l'utiliser. Sinon, vous risquez de committer des fichiers temporaires, des dépendances ou des secrets.

Ajouter des parties d'un fichier (staging interactif)

Pour n'indexer que certaines modifications d'un fichier, utilisez le mode patch :

git add -p style.css

Git vous présente chaque bloc de modifications (appelé hunk) et vous demande quoi en faire :

@@ -1,5 +1,6 @@
 body {
   font-family: sans-serif;
+  color: #333;
   margin: 0;
   padding: 0;
 }
Stage this hunk [y,n,q,a,d,s,e,?]?

Les options principales :

Touche	Action
y	Indexer ce bloc
n	Ne pas indexer ce bloc
q	Quitter (ne plus proposer de blocs)
s	Découper le bloc en morceaux plus petits

Glissez pour voir

Le staging interactif vous permet de créer des commits propres et ciblés, même quand vous avez fait plusieurs modifications dans le même fichier.

Inspecter les différences avec git diff

Avant de committer, inspectez ce qui a changé pour vérifier que vos modifications sont correctes.

Voir les modifications non indexées

git diff

Cette commande compare le Working Directory avec la Staging Area. Elle montre ce que vous avez modifié mais pas encore ajouté avec git add.

Sortie attendue :

diff --git a/style.css b/style.css
index 1234567..abcdefg 100644
--- a/style.css
+++ b/style.css
@@ -1,5 +1,6 @@
 body {
   font-family: sans-serif;
+  color: #333;
   margin: 0;
   padding: 0;
 }

Les lignes préfixées par + sont des ajouts, celles par - sont des suppressions. Le contexte (lignes sans préfixe) vous aide à situer les modifications.

Voir les modifications indexées (prêtes à committer)

git diff --staged

Cette commande compare la Staging Area avec le dernier commit. Elle montre exactement ce qui sera enregistré au prochain git commit.

Résumé des commandes diff

La distinction à retenir est celle des deux points de comparaison. git diff seul regarde ce qui n'est pas encore indexé, git diff --staged regarde ce qui l'est déjà. C'est la source de confusion la plus fréquente chez les débutants : un git diff qui n'affiche rien ne signifie pas que le travail est vide, mais souvent que tout est déjà dans la Staging Area. La troisième ligne, git diff HEAD, cumule les deux et montre l'écart total avec le dernier commit.

Commande	Compare	Montre
git diff	Working Dir ↔ Staging	Modifications non indexées
git diff --staged	Staging ↔ Dernier commit	Ce qui sera committé
git diff HEAD	Working Dir ↔ Dernier commit	Toutes les modifications

Glissez pour voir

Créer un commit

Un commit enregistre le contenu de la Staging Area comme un nouveau snapshot dans l'historique. Chaque commit est identifié par un SHA unique et contient un message descriptif.

Commit avec message en ligne

L'option -m est la forme la plus rapide : le message tient sur une ligne, sans ouvrir d'éditeur. Elle convient aux modifications simples qu'une phrase décrit entièrement. Dès que le changement mérite une explication du pourquoi, préférez la forme sans -m détaillée juste après.

git commit -m "Ajouter la page d'accueil et les styles de base"

Sortie attendue :

[main 3f7a2b1] Ajouter la page d'accueil et les styles de base
 2 files changed, 45 insertions(+)
 create mode 100644 index.html
 create mode 100644 style.css

Commit avec message détaillé

Pour les modifications plus complexes, ouvrez votre éditeur pour écrire un message sur plusieurs lignes :

git commit

Git ouvre l'éditeur configuré. Écrivez un titre court (50 caractères max), une ligne vide, puis une description détaillée :

Ajouter l'authentification des utilisateurs

- Créer le formulaire de connexion (login.html)
- Valider la saisie côté client (auth.js)
- Mettre en forme le formulaire (auth.css)

Raccourci : add + commit en une seule commande

Pour les fichiers déjà suivis par Git (pas les nouveaux fichiers) :

git commit -am "Corriger la couleur du texte"

L'option -a ajoute automatiquement tous les fichiers modifiés suivis à la Staging Area avant de committer. Les fichiers non suivis (untracked) ne sont pas inclus.

Modifier le dernier commit

Vous avez oublié un fichier ou fait une faute dans le message ?

git add fichier-oublie.css
git commit --amend

Git ouvre l'éditeur pour modifier le message, et le fichier oublié est inclus dans le commit. Le SHA du commit change car le contenu est différent.

Attention avec --amend

N'utilisez --amend que sur des commits pas encore poussés vers un serveur distant. Modifier un commit déjà partagé peut causer des conflits pour les autres membres de l'équipe.

Écrire de bons messages de commit

Un bon message de commit aide à comprendre l'historique du projet. Voici les conventions les plus répandues. Cette formation écrit les titres à l'infinitif (« Ajouter », « Corriger ») ; l'impératif (« Ajoute ») est tout aussi courant, l'essentiel est qu'un dépôt garde un seul registre :

Règle	Exemple
Titre court (50 car. max)	Ajouter la page de contact
Verbe à l'infinitif	Ajouter (pas "Ajouté" ni "Ajout de")
Ligne vide après le titre	Sépare le titre du corps
Corps optionnel (72 car./ligne)	Explique le pourquoi, pas le quoi

Glissez pour voir

Convention Conventional Commits

En équipe, ajoutez un type devant le titre, au format Conventional Commits :

feat: ajouter le formulaire de contact
fix: corriger le calcul du prix TTC
docs: mettre à jour le README
refactor: extraire la logique d'authentification

Le type s'écrit en minuscules et la description commence elle aussi par une minuscule, contrairement au tableau ci-dessus : dans le préréglage @commitlint/config-conventional, la règle subject-case interdit les casses sentence-case (« Ajouter le formulaire »), start-case, pascal-case et upper-case. Une description qui commence par une majuscule est donc refusée, alors que la minuscule initiale passe. Ce format facilite la génération automatique de changelogs et sa vérification par un outil. Il est enseigné dans la leçon Conventional Commits, dans le module consacré à la collaboration.

Retirer des fichiers de l'index

Désindexer un fichier (sans perdre les modifications)

Si vous avez ajouté un fichier par erreur à la Staging Area :

git restore --staged style.css

Le fichier revient à l'état "modifié" dans le Working Directory. Vos modifications ne sont pas perdues.

Avant Git 2.23

L'ancienne commande git reset HEAD style.css fait la même chose. git restore --staged est plus claire car elle ne sert qu'à retirer de la Staging Area, sans autre effet.

Supprimer un fichier du suivi Git

Pour supprimer un fichier et l'enlever du suivi Git :

git rm ancien-fichier.txt

Pour arrêter de suivre un fichier sans le supprimer du disque (utile si vous l'avez committé par erreur) :

git rm --cached fichier-secret.env

Le fichier reste sur votre disque mais Git ne le suit plus. Pensez à l'ajouter au .gitignore pour éviter de le ré-indexer. Attention : cette commande ne retire rien des commits déjà faits. Un secret committé par erreur reste lisible dans l'historique et doit d'abord être révoqué, comme l'explique la leçon Pourquoi versionner.

Configurer le .gitignore

Le fichier .gitignore indique à Git quels fichiers et dossiers ignorer. Ces fichiers n'apparaîtront plus dans git status et ne seront jamais indexés par git add ., sauf s'ils sont déjà suivis.

Cette section couvre ce qu'il faut savoir pour démarrer. Pour les trois sources de règles, la vérification de ce que Git prend réellement en compte avec git check-ignore, et le cas du fichier déjà suivi qu'aucune règle ne filtre plus, voyez le guide dédié ignorer des fichiers avec .gitignore.

Syntaxe de base

Chaque ligne du .gitignore est un motif. Deux caractères font tout le travail : * remplace n'importe quelle suite de caractères, et / en fin de ligne désigne un dossier entier. Le point le plus contre-intuitif est le !, qui réintègre un fichier qu'un motif précédent excluait ; l'ordre des lignes compte donc, une exception doit venir après la règle qu'elle contredit.

# Commentaire
*.log           # Tous les fichiers .log
node_modules/   # Tout le dossier node_modules
!important.log  # Exception : suivre ce fichier malgré *.log
build/          # Dossier de build
.env            # Fichier d'environnement (secrets)

Les patterns les plus courants

Ces motifs couvrent la quasi-totalité des besoins réels. Regardez surtout les deux derniers, plus subtils : doc/**/*.pdf utilise le double astérisque pour traverser tous les sous-dossiers, alors qu'un / en tête comme dans /TODO ancre le motif à la racine du dépôt et n'affecte pas les fichiers TODO situés plus profond. Confondre ces deux comportements est la cause classique d'un fichier qu'on croyait ignoré et qui apparaît quand même dans git status.

Pattern	Correspond à
*.log	Tous les fichiers terminant par .log
build/	Le dossier build et tout son contenu
doc/**/*.pdf	Tous les .pdf dans doc/ et ses sous-dossiers
!README.md	Exception : ne pas ignorer ce fichier
/TODO	Seulement le fichier TODO à la racine

Glissez pour voir

Modèles .gitignore par langage

GitHub maintient une collection de modèles .gitignore pour chaque langage et framework : github.com/github/gitignore.

Quelques exemples courants :

Python

__pycache__/
*.py[cod]
.venv/
*.egg-info/
dist/
.env

Node.js

node_modules/
dist/
.env
*.log
coverage/

Go

/bin/
*.exe
*.test
go.work

Gitignore global

Pour ignorer des fichiers communs à tous vos projets (.DS_Store, .idea/, *.swp), configurez un gitignore global :

git config --global core.excludesFile ~/.gitignore_global

Ainsi, vos préférences d'éditeur n'encombrent pas le .gitignore du projet.

Dépannage : problèmes courants

La plupart des blocages du cycle add puis commit se résument à quelques symptômes récurrents. Lisez ce tableau de la colonne de gauche vers la droite : partez du message ou du comportement que vous observez, puis appliquez la solution. Le cas le plus déroutant pour un débutant est le git diff qui n'affiche rien, expliqué plus haut, presque toujours dû à des modifications déjà indexées.

Symptôme	Cause probable	Solution
git add n'ajoute pas un fichier	Le fichier est dans .gitignore	Vérifiez .gitignore ou utilisez git add -f fichier
Fichier committé par erreur	Déjà dans l'historique	git rm --cached fichier + ajouter au .gitignore
git diff ne montre rien	Modifications déjà indexées	Utilisez git diff --staged
nothing to commit, working tree clean	Tous les fichiers sont committés	Normal : faites une modification et recommencez
Message de commit erroné	Faute de frappe	git commit --amend (si pas encore poussé)

Glissez pour voir

À retenir

• git status est votre meilleur ami : utilisez-le avant chaque add et chaque commit
• git add place les modifications dans la Staging Area, utilisez -p pour un contrôle granulaire
• git diff (non indexé) et git diff --staged (indexé) vous montrent exactement ce qui va se passer
• git commit -m "message" enregistre le snapshot dans l'historique
• .gitignore protège votre dépôt des fichiers indésirables, créez-le avant le premier commit
• Ne committez jamais de secrets : .env, clés, tokens → dans le .gitignore

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →