git add et git commit : bien enregistrer ses modifications

Git n'a pas de bouton « Enregistrer ». Les modifications s'enregistrent en deux étapes : git add sélectionne d'abord les changements qui feront partie du prochain instantané, puis git commit inscrit cet instantané dans l'historique. La zone intermédiaire entre les deux s'appelle l'index, ou staging area. Beaucoup ne la comprennent pas pendant des années — et c'est pourtant elle qui donne du sens aux commits.

Les trois états d'un fichier : répertoire de travail, index, historique

Toute modification traverse trois zones :

1. Le répertoire de travail — vous modifiez le fichier dans votre éditeur.
2. L'index (stage) — git add place la version actuelle du fichier dans le brouillon du prochain commit.
3. L'historique — git commit transforme le contenu de l'index en commit avec auteur, date et message.

Une analogie pratique : le colis. Le répertoire de travail, c'est la pièce avec vos affaires ; l'index, c'est le carton ouvert dans lequel vous mettez ce que vous voulez envoyer ; le commit, c'est le colis fermé et étiqueté. Vous choisissez ce que vous mettez dans le carton, et rien ne vous oblige à tout envoyer d'un coup.

À quoi sert l'index

Imaginez : en une heure, vous avez corrigé un bug d'authentification, rectifié au passage une coquille dans le README et commencé une nouvelle fonctionnalité. Sans index, tout cela finirait dans un seul commit « divers ». Avec l'index, vous faites trois commits distincts, chacun facile à comprendre, à relire en revue de code et, si besoin, à annuler sans toucher au reste.

git status : ce qui est modifié et ce qui est prêt

Avant chaque add et chaque commit, prenez l'habitude de lancer git status. C'est la commande la plus sûre de Git : elle ne modifie rien.

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/auth.js

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:   README.md

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

• Changes to be committed — déjà dans l'index, fera partie du commit ;
• Changes not staged — modifié, mais pas ajouté ;
• Untracked files — nouveaux fichiers que Git ne connaît pas encore.

Le format court est plus pratique quand les fichiers sont nombreux :

$ git status -s
M  src/auth.js
 M README.md
?? src/profile.js

La première colonne indique l'état dans l'index, la seconde dans le répertoire de travail. Un M à gauche signifie « modifié et ajouté », à droite « modifié, non ajouté » ; ?? signifie « non suivi ».

git add : ajouter des modifications à l'index

git stage est un synonyme de git add : c'est la même commande, d'où le terme « stage » et l'expression « stager un fichier ».

git add -p : ajouter une partie d'un fichier

La technique la plus sous-estimée. Si un même fichier mélange deux modifications sans rapport, git add -p vous présente chaque fragment et vous demande s'il faut l'ajouter :

$ git add -p src/auth.js
@@ -12,7 +12,7 @@ function login(user) {
-  if (user.password = input) {
+  if (user.password === input) {
(1/2) Stage this hunk [y,n,q,a,d,s,e,?]?

y — ajouter, n — ignorer, s — découper le fragment plus finement, q — quitter. Un seul fichier donne ainsi deux commits propres.

Vérifier exactement ce qui partira dans le commit

git diff            # modifications PAS encore ajoutées à l'index
git diff --staged   # ce qui est déjà dans l'index et fera partie du commit

Confusion fréquente : après git add, un simple git diff n'affiche plus rien. Les modifications n'ont pas disparu — elles sont dans l'index, consultez git diff --staged (synonyme : --cached).

Retirer un fichier de l'index

git restore --staged file.js

Les modifications du fichier restent intactes ; il n'est simplement plus préparé pour le commit. Dans les anciennes versions de Git, on utilisait git reset HEAD file.js — cela fonctionne toujours.

git commit : enregistrer les modifications

git commit -m "Corriger la vérification du mot de passe à la connexion"

[main 3f2a9c1] Corriger la vérification du mot de passe à la connexion
 1 file changed, 1 insertion(+), 1 deletion(-)

La réponse indique la branche, le hash court du nouveau commit et des statistiques. Seul le contenu de l'index entre dans le commit. Si vous avez retouché le fichier après git add, ces nouvelles modifications n'y figureront pas tant que vous ne les aurez pas ajoutées à nouveau.

Les options utiles de git commit

Si votre éditeur par défaut est Vim et que vous y êtes coincé : écrivez le message, appuyez sur Esc, puis tapez :wq et Entrée. Pour changer d'éditeur : git config --global core.editor "code --wait" ou nano.

Bien rédiger un message de commit

Un message de commit est relu six mois plus tard, quand on cherche l'origine d'un bug. Il doit répondre à « quoi et pourquoi », pas à « ce que j'ai fait aujourd'hui ».

• première ligne de 50 à 72 caractères maximum, l'essentiel du changement ;
• à l'impératif ou à l'infinitif, de façon neutre : « Ajouter la validation de l'e-mail », « Fix login redirect » ;
• si nécessaire, une ligne vide puis les détails : pourquoi ce choix, quelles limites ;
• un commit = une modification logique.

Mauvais : fix, modifs, wip, asdf. Bon : Corriger le plantage du panier quand la liste de produits est vide. Beaucoup d'équipes utilisent la convention Conventional Commits : feat: ..., fix: ..., docs: ....

git commit --amend : corriger le dernier commit

Une coquille dans le message ou un fichier oublié ? Inutile de faire un nouveau commit « fichier oublié ». C'est le rôle d'amend.

Corriger le message

git commit --amend -m "Corriger la vérification du mot de passe à la connexion"

Ajouter un fichier oublié

git add forgotten.js
git commit --amend --no-edit

L'option --no-edit conserve le message précédent.

Ce qu'il faut savoir sur amend

--amend ne « modifie » pas le commit : il en crée un nouveau, avec un autre hash, qui remplace l'ancien. Tant que le commit n'existe que chez vous, c'est sans danger. Si vous avez déjà fait git push, un push normal sera refusé après l'amend et vous devrez utiliser git push --force-with-lease. Évitez-le sur les branches partagées où d'autres travaillent : vous réécririez un historique sur lequel ils construisent déjà.

Si vous avez fait un amend par erreur, retrouvez l'ancien commit dans git reflog et revenez-y avec git reset --soft HEAD@{1}.

Erreurs courantes

« nothing to commit, working tree clean »

Aucune modification : tout est déjà committé, ou vous modifiez un fichier dans un autre dossier. Vérifiez git status et le chemin du projet.

« no changes added to commit »

Des fichiers sont modifiés, mais ne sont pas dans l'index. Lancez git add ou utilisez git commit -am pour les fichiers déjà suivis.

« Please tell me who you are »

Le nom et l'e-mail ne sont pas configurés. Exécutez une fois git config --global user.name "Nom" et git config --global user.email "e-mail".

Vous avez committé quelque chose en trop

Si le commit n'a pas encore été poussé, annulez-le en gardant les modifications dans l'index : git reset --soft HEAD~1. Retirez ensuite le superflu avec git restore --staged et committez à nouveau. Si un secret s'est glissé dans le commit, considérez-le comme compromis et régénérez-le.

git add . a ajouté des fichiers parasites

Configurez .gitignore en amont et consultez git status avant de committer. Un fichier déjà suivi ne cesse de l'être qu'après git rm --cached fichier.

Ce qu'est réellement un commit

Un commit ne stocke pas la différence avec la version précédente, mais un instantané de tout le projet : une référence vers l'arbre des fichiers, une référence vers le commit parent, l'auteur, la date et le message. Les fichiers inchangés ne sont pas recopiés — Git pointe vers les objets déjà stockés, l'historique occupe donc peu de place.

Le hash du commit (par exemple 3f2a9c1) est calculé à partir de tout ce contenu. Changez une seule lettre du message et vous obtenez un autre hash. Voilà pourquoi --amend et rebase créent de nouveaux commits au lieu de modifier les anciens, et pourquoi un historique réécrit entre en conflit avec les copies de vos collègues.

Pour consulter l'historique de façon condensée :

git log --oneline --graph -10

Chaque ligne est un commit ; si les messages de votre historique se comprennent sans ouvrir le diff, vous êtes sur la bonne voie.

Le cycle de travail au quotidien

git status                 # ce qui a changé
git diff                   # voir les modifications
git add -p                 # sélectionner ce qu'il faut
git diff --staged          # vérifier ce qui partira dans le commit
git commit -m "Description claire"
git log --oneline -5       # s'assurer que le commit est bien là
git push                   # envoyer au serveur

Un commit n'enregistre les modifications qu'en local. Pour qu'elles arrivent sur GitHub ou un autre serveur, il faut git push.

En résumé

git add prépare le prochain instantané dans l'index, git status et git diff --staged montrent ce qu'il contiendra, et git commit l'inscrit dans l'historique. Faites des commits petits et logiques avec des messages clairs, et pour les petites corrections du dernier commit utilisez git commit --amend — avant le push. L'index et le schéma en deux temps add → commit sont mis en pratique dans le cours Git.