Le modèle Git : snapshots, SHA et 3 états

Ce guide vous explique comment Git pense. Avant de taper la moindre commande, comprendre le modèle interne de Git vous évitera 90 % des erreurs courantes. Vous apprendrez comment Git stocke vos données (snapshots), comment il identifie chaque version (SHA), et comment vos fichiers transitent entre les 3 états fondamentaux (Working Directory, Staging Area, Repository).

Prérequis : aucun. Ce guide est le point de départ recommandé pour tout débutant.

Ce que vous allez apprendre

Le modèle snapshot : pourquoi Git ne stocke pas des différences mais des photos complètes de votre projet
Les identifiants SHA : comment Git donne un nom unique et infalsifiable à chaque version
Les 3 états : le circuit que suivent vos fichiers avant d’être enregistrés dans l’historique
L’anatomie d’un commit : ce que contient réellement un commit Git

Snapshots vs deltas : deux façons de versionner

Pour comprendre Git, comparons-le à ses prédécesseurs. La plupart des anciens systèmes de version (CVS, Subversion) stockent les deltas : ils enregistrent la liste des différences entre chaque version d’un fichier.

Git fait l’inverse. À chaque commit, Git prend une photo complète (snapshot) de tous vos fichiers. Si un fichier n’a pas changé, Git ne le duplique pas : il stocke simplement une référence vers la version précédente déjà enregistrée.

Comparaison entre le stockage par deltas (SVN) et par snapshots (Git)

Pourquoi les snapshots sont plus performants

Cette approche donne à Git plusieurs avantages concrets :

Aspect	Deltas (SVN, CVS)	Snapshots (Git)
Voir une version passée	Recalculer toutes les différences depuis le début	Charger directement le snapshot
Vitesse sur gros projets	Ralentit avec l’historique	Reste rapide
Travail hors-ligne	Impossible (serveur requis)	Tout l’historique est local
Intégrité des données	Pas de vérification native	Chaque objet est vérifié par son SHA

En pratique, quand vous faites git log ou git diff, Git accède directement aux snapshots concernés au lieu de recalculer les différences depuis le début du projet. C’est ce qui rend Git rapide, même sur des projets avec des milliers de commits.

Les identifiants SHA : l’empreinte digitale de chaque version

Chaque objet dans Git (commit, fichier, arborescence) est identifié par un hash SHA-1 de 40 caractères hexadécimaux. Ce hash est calculé à partir du contenu de l’objet.

e4a1c0f7d3b5a9e2c8f1d6b4a7e3c9f5a2d8b1e6

Ce n’est pas le fruit du hasard : c’est une empreinte mathématique unique. Si un seul octet change dans le contenu, le SHA change complètement.

Ce que le SHA garantit

Le SHA n’est pas seulement un identifiant. Il apporte deux garanties fondamentales :

Intégrité : si les données sont corrompues (disque défaillant, transfert réseau), le SHA ne correspondra plus au contenu. Git détecte automatiquement le problème.
Unicité : deux fichiers différents ne produiront (quasiment) jamais le même SHA. Vous pouvez identifier un commit par ses 7-8 premiers caractères sans ambiguïté.

En pratique, vous verrez souvent des SHA abrégés dans la sortie de git log :

e4a1c0f (HEAD -> main) Ajout de la page d'accueil
a3b7d2e Création du fichier README

Git accepte les SHA abrégés tant qu’ils sont non ambigus (généralement 7 caractères suffisent).

Les 3 états de Git

C’est le concept le plus important à comprendre. Chaque fichier de votre projet passe par 3 zones distinctes avant d’être définitivement enregistré dans l’historique.

Les trois états de Git : répertoire de travail, zone de staging et dépôt

Working Directory (répertoire de travail)

C’est le dossier de votre projet tel que vous le voyez sur votre disque. Quand vous ouvrez un fichier dans votre éditeur de texte et que vous le modifiez, vous travaillez dans le Working Directory.

Staging Area (zone de transit)

La Staging Area (aussi appelée Index) est une zone intermédiaire où vous préparez votre prochain commit. Quand vous exécutez git add, vous déplacez un fichier du Working Directory vers la Staging Area.

L’intérêt de cette zone intermédiaire est de vous permettre de choisir exactement quelles modifications inclure dans votre prochain commit. Vous avez peut-être modifié 10 fichiers, mais seuls 3 concernent la même fonctionnalité. La Staging Area vous permet de ne committer que ces 3 fichiers.

Repository (dépôt)

Le Repository est la base de données de Git, stockée dans le dossier .git/ à la racine de votre projet. C’est ici que Git conserve tout l’historique de vos commits, vos branches, vos tags et vos configurations.

Quand vous exécutez git commit, Git crée un nouveau snapshot dans le Repository. Ce snapshot est permanent et identifié par son SHA unique.

Le cycle complet en pratique

Voici ce qui se passe concrètement quand vous travaillez avec Git :

Vous modifiez un fichier dans votre éditeur. Le fichier passe à l’état “modifié” dans le Working Directory.
Vous exécutez git add pour placer ce fichier dans la Staging Area. Le fichier passe à l’état “indexé” (staged).
Vous exécutez git commit pour enregistrer le snapshot dans le Repository. Le fichier passe à l’état “committé”.

Pour vérifier dans quel état se trouvent vos fichiers, utilisez git status :

git status

Sortie attendue (exemple avec un fichier modifié et un fichier indexé) :

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   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

Dans cet exemple, index.html est dans la Staging Area (prêt à être committé) et style.css est modifié dans le Working Directory mais pas encore ajouté à la Staging Area.

Anatomie d’un commit

Un commit Git n’est pas qu’un simple “enregistrement de fichiers”. C’est un objet structuré qui contient plusieurs informations :

Champ	Contenu	Exemple
SHA	Identifiant unique du commit	`e4a1c0f7d3b5a9e2...`
Tree	Référence vers le snapshot (arborescence complète)	`a1b2c3d4...`
Parent(s)	SHA du ou des commits précédents	`f5e6d7c8...`
Author	Qui a écrit les modifications	`Alice <alice@dev.com>`
Committer	Qui a créé le commit	`Bob <bob@ops.com>`
Date	Quand le commit a été créé	`2026-03-28 10:30:00`
Message	Description des modifications	`Ajout de la page de contact`

Le champ Parent est ce qui crée la chaîne de l’historique. Chaque commit pointe vers son prédécesseur, formant un graphe orienté. Le premier commit du projet n’a pas de parent ; un commit de merge en a deux.

Presque tout est local

Un des avantages fondamentaux de Git est que presque toutes les opérations sont locales. Contrairement à Subversion qui nécessite une connexion au serveur pour consulter l’historique ou créer une branche, Git dispose de toute l’information sur votre machine.

Les conséquences pratiques :

Consulter l’historique (git log) : instantané, pas de requête réseau
Comparer deux versions (git diff) : tout se passe en local
Créer une branche (git branch) : un fichier de 41 octets est créé, c’est tout
Travailler dans le train sans WiFi : aucun problème, vous synchroniserez plus tard

Seules les opérations qui impliquent un serveur distant (push, pull, fetch, clone) nécessitent une connexion réseau.

Git n’efface (presque) rien

Une fois qu’un fichier est committé dans Git, il est très difficile de le perdre. Même si vous supprimez une branche, les commits restent dans la base de données de Git pendant au moins 30 jours (via le reflog).

Cette propriété est rassurante pour les débutants : tant que vous committez régulièrement, vous pouvez toujours revenir en arrière. Les erreurs ne sont jamais définitives.

Dépannage : questions fréquentes

Question	Réponse
”C’est quoi la différence entre `git add` et `git commit` ?”	`git add` place les fichiers dans la Staging Area (panier). `git commit` enregistre le snapshot dans le Repository (caisse).
”Pourquoi mes modifications n’apparaissent pas dans `git log` ?”	Vous avez probablement oublié de faire `git commit`. Vérifiez avec `git status`.
”C’est quoi ce numéro bizarre après chaque commit ?”	C’est le SHA, l’identifiant unique du commit. Pensez-y comme une empreinte digitale.
”Je peux annuler un `git add` ?”	Oui : `git restore --staged fichier` retire le fichier de la Staging Area sans perdre vos modifications.
”Si je supprime un fichier, Git le perd ?”	Non. Tant que le fichier a été committé au moins une fois, il est dans l’historique et récupérable.

À retenir

Git stocke des snapshots, pas des différences. Chaque commit est une photo complète de votre projet.
Le SHA est l’empreinte digitale unique de chaque objet Git. Il garantit l’intégrité des données.
Les 3 états : Working Directory (votre bureau) → Staging Area (votre panier) → Repository (le coffre-fort).
git add déplace vers la Staging Area, git commit enregistre dans le Repository.
Presque tout est local : Git ne nécessite une connexion réseau que pour synchroniser avec un serveur distant.
Git n’efface presque rien : tant que vous committez, vous pouvez toujours revenir en arrière.

Prochaines étapes

Installer et configurer Git Préparez votre poste de travail avec Git correctement configuré.

Créer un dépôt Git Mettez en pratique : créez votre premier dépôt et explorez sa structure.

Enregistrer des modifications Maîtrisez le cycle add → commit au quotidien.