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 :

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.

Analogie

git add, c’est remplir votre panier de courses. Vous parcourez les rayons (vos fichiers modifiés) et choisissez ce que vous mettez dans le panier. Ce n’est qu’en passant en caisse (git commit) que vos achats sont définitivement enregistrés.

Ajouter un fichier spécifique

git add index.html

Ajouter plusieurs fichiers

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

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

git commit -m "Ajout de la page d'accueil et des styles de base"

Sortie attendue :

[main 3f7a2b1] Ajout de la page d'accueil et des 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 :

Ajout du système d'authentification utilisateur

- Création du formulaire de connexion (login.html)
- Ajout de la validation côté client (auth.js)
- Configuration des styles pour 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 "Correction de 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 :

Règle	Exemple
Titre court (50 car. max)	Ajout de la page de contact
Verbe à l’impératif	Ajoute (pas “Ajouté” ou “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, adoptez le format Conventional Commits :

feat: ajout du formulaire de contact
fix: correction du calcul du prix TTC
docs: mise à jour du README
refactor: extraction de la logique d'auth

Ce format facilite la génération automatique de changelogs et la lecture de l’historique.

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.

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.

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 ..

Syntaxe de base

# 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

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

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

Prochaines étapes

Consulter l'historique Explorez vos commits avec git log : filtrer, chercher, formater.

Annuler des modifications Corrigez vos erreurs avec restore, amend et revert.

Le modèle Git : snapshots et 3 états Revenez aux fondamentaux pour mieux comprendre le cycle add → commit.

×

📖 Voir la documentation →