Comment fonctionne Git en interne ?

Question

Accepted Answer

En interne, Git est un **magasin d'objets adressable par contenu** — il stocke tout sous forme d'**objets** (blobs, trees, commits, tags) identifiés par leur **hash SHA-1**. Comprendre ce modèle démystifie Git et explique pourquoi ses opérations se comportent comme elles le font.

## Git est un magasin d'objets adressable par contenu

```text
Git stores 4 types of OBJECTS, each identified by the SHA-1 HASH of its content:
  BLOB   → file CONTENTS (just the data, no filename)
  TREE   → a directory: maps names → blobs (files) and trees (subdirs) + permissions
  COMMIT → a snapshot: points to a TREE (the root) + parent commit(s) + author/message
  TAG    → an annotated tag object (points to a commit, with metadata)
→ Content-addressable: an object's ID IS the hash of its content (same content = same hash).
```

## Un commit est un snapshot, pas un diff

```text
→ Each COMMIT points to a complete TREE (the full state of the project at that point)
→ Git stores SNAPSHOTS, not diffs (though it compresses/deduplicates internally):
  unchanged files → the commit's tree just REUSES the same blob (same hash) → efficient
→ Diffs you see are COMPUTED between snapshots, not stored.
```

## Comment tout s'emboîte

```text
Branch (e.g. main) → a pointer (a ref) to a COMMIT
HEAD → points to the current branch (or commit)
Commit → tree → blobs (the snapshot)
Commit → parent → parent → ... (the history chain)
→ Branches/tags are just small files containing a commit hash (cheap pointers).
  That's WHY branching is so lightweight.
```

## Pourquoi cela explique le comportement de Git

```text
✓ Branches are cheap → they're just a 40-char hash in a file (not file copies)
✓ Integrity → content-addressing means corruption/changes are detectable (hash mismatch)
✓ Commits are immutable → changing anything = a new hash = a new commit (why rebase
  creates NEW commits, why history rewriting changes hashes)
✓ Deduplication → identical content stored once (shared blobs)
```

## Pourquoi c'est important

Comprendre comment fonctionne Git en interne est une connaissance précieuse de niveau senior car elle **démystifie Git** et explique *pourquoi* ses opérations se comportent comme elles le font, approfondissant votre capacité à raisonner sur Git et à l'utiliser en confiance.

Le modèle fondamental — Git en tant que **magasin d'objets adressable par contenu** avec quatre types d'objets (blobs pour les contenus de fichiers, trees pour les répertoires, commits pour les snapshots, tags) chacun identifié par le **hash de son contenu** — est la fondation sur laquelle tout le reste repose.

Comprendre qu'**un commit est un snapshot, pas un diff** (chaque commit pointe vers un tree complet représentant l'état complet du projet, avec les fichiers inchangés réutilisant efficacement les mêmes blobs, et les diffs calculés plutôt que stockés) corrige une idée fausse courante et explique le modèle basé sur les snapshots de Git.

Voir **comment tout s'emboîte** (branches et tags en tant que pointeurs/références bon marché aux commits, HEAD pointant vers la branche actuelle, commits chaînés via leurs parents) révèle l'élégante simplicité qui se cache en dessous.

Plus précieusement, cette compréhension **explique le comportement observable de Git** : pourquoi les **branches sont légères** (juste un hash dans un petit fichier, pas des copies de fichiers — expliquant pourquoi la création de branches est si rapide), pourquoi Git a **l'intégrité** (l'adressage par contenu détecte la corruption via les non-concordances de hash), pourquoi les **commits sont immuables** et les opérations de réécriture d'historique comme rebase créent des **nouveaux commits avec de nouveaux hash** (modifier n'importe quel contenu modifie le hash), et pourquoi Git **déduplique** (le contenu identique est stocké une seule fois).

Ce modèle plus profond transforme Git d'un ensemble de commandes mémorisées en un système compréhensible, permettant un raisonnement confiant sur les opérations complexes.

Étant donné que comprendre le modèle d'objet interne explique pourquoi Git se comporte comme il le fait (branches légères, commits immuables, changements de hash lors de la réécriture, intégrité) et élève quelqu'un d'utiliser Git à vraiment le comprendre, comprendre les internals de Git est une connaissance précieuse de niveau senior — un sujet qui reflète la profondeur attendue pour les rôles seniors et fournit le modèle mental pour raisonner sur Git en confiance, démystifiant son comportement et rendant les opérations avancées compréhensibles plutôt que mystérieuses.