Git ne stocke pas tes modifications
Contrairement à l'intuition, Git n'enregistre pas tes changements : chaque commit est une copie complète, adressée par le hash de son contenu.
53s · 1 juillet 2026 · 1 min de lecture
En bref
Git n'est pas un empileur de différences. À chaque commit, il prend un instantané complet de ton projet. Chaque fichier est identifié par l'empreinte de son contenu, ce qui évite tout doublon — et enchaîne l'historique de façon vérifiable.
Snapshots, pas diffs
La plupart des outils de version stockent une version d'origine, puis une suite de changements. Git fait l'inverse. À chaque commit, il enregistre un instantané complet de ton projet : le commit pointe vers une arborescence qui décrit tous les fichiers à cet instant — pas seulement ce qui a bougé.
Ce que tu crois
- Une pile de diffs
- Git stocke les changements
La réalité
- Un instantané complet
- Git stocke des objets adressés par leur contenu
→ Vois Git comme une base de données de contenus, pas comme un journal de modifications.
Adressé par le contenu
Tout ce que Git connaît vit dans .git/objects sous forme d'objets : des blobs (le contenu d'un fichier), des trees (un dossier) et des commits (un instantané plus ses métadonnées). Chaque objet est nommé par le hash de son propre contenu. Par défaut, c'est une empreinte SHA-1 de 40 caractères ; les versions récentes de Git prennent aussi en charge SHA-256.
echo "Hello, world!" | git hash-object --stdin
# a0b65939670bc350e3d7bb401cfd2e68aa5bdfa6Pourquoi ce n'est pas énorme
Un instantané complet à chaque commit, ça semble gigantesque. Mais comme chaque objet est nommé par son contenu, un fichier inchangé garde la même empreinte : Git ne le re-stocke pas, il le référence. Un commit ne crée donc de nouveaux objets que le long du chemin qui a vraiment changé. Tout le reste est partagé.
40caractères
l'empreinte SHA-1 qui nomme chaque objet (64 en SHA-256)
source : git-scm
Une histoire qu'on ne réécrit pas en douce
Change un seul octet dans un fichier, et son blob change d'empreinte. L'arborescence qui le contient change donc aussi, puis le commit, puis tous les commits suivants. C'est pour ça que tu ne peux pas modifier discrètement le passé : la moindre altération se propage à toutes les empreintes en aval, et devient visible.
À retenir
- →Chaque commit est un instantané complet du projet, pas une liste de différences.
- →Chaque objet (blob, tree, commit) est nommé par le hash de son contenu — SHA-1 par défaut, SHA-256 en option.
- →Un fichier inchangé garde la même empreinte : il est référencé, jamais dupliqué.
- →Changer un octet change toutes les empreintes en aval — l'historique est vérifiable, pas réécrivable en douce.
Sources · la preuve
- [01] Git Internals — Git Objects Pro Git (git-scm) · git-scm.com Référence officielle : blob, tree, commit et stockage par SHA-1.
- [02] Git: Snapshots, not diffs Código del Sur · codigodelsur.com Les commits sont des instantanés ; fichiers inchangés référencés, pas dupliqués.
- [03] How Git Actually Stores Your Code DEV · dev.to Déduplication par contenu ; SHA-1 par défaut, SHA-256 supporté.
- [04] Understanding How Git Stores Data Ken Muse · kenmuse.com Système de fichiers adressable par contenu ; propagation des SHA.
