Pro Git

1Snapshots, pas des diffs : le changement de paradigme

Git ne stocke pas ce qui a changé. Il prend une photo de tout, à chaque commit. « Avec Git, chaque fois que vous committez, Git prend une photo de l'état de tous vos fichiers à ce moment et stocke une référence à ce snapshot » (p. 14). Les autres systèmes (CVS, Subversion) stockent les fichiers plus une série de deltas. Pour reconstruire la version 37, ils rejouent toutes les modifications depuis la version 1. Git stocke directement la version 37. C'est pour ça que Git n'a pas besoin du serveur pour consulter l'historique, qu'il est rapide, et que chaque clone est une sauvegarde complète.

2Tout a une empreinte SHA-1 : rien ne se perd en silence

« Tout ce qui est stocké dans Git est vérifié par une somme de contrôle avant d'être stocké, puis référencé par cette empreinte » (p. 15). Cette empreinte est un hash SHA-1, 40 caractères hexadécimaux, et vous pouvez le recalculer vous-même :

echo "bonjour" | git hash-object --stdin   # → le SHA-1 du contenu, calculé sous vos yeux
git cat-file -t HEAD                       # → "commit" : le type de l'objet
git cat-file -p HEAD                       # → le commit en clair (arbre, parent, auteur, message)

Le même contenu donne toujours le même hash : modifier un fichier sans que Git le sache est donc impossible. Git ne fait presque qu'ajouter des données : une fois un commit enregistré, il est quasi indestructible. La seule vraie exception, qui efface pour de bon : git reset --hard.

3Les trois états et la zone de staging

Un fichier dans Git est dans l'un des trois états : modifié (changé mais pas encore indexé), indexé (marqué pour le prochain commit), ou enregistré dans Git (sauvegardé de façon permanente). La zone de staging est la pièce maîtresse : c'est un fichier dans .git/ qui contient exactement ce qui ira dans le prochain snapshot.

C'est ce qui permet de ne commiter qu'une partie de ses changements, ou de construire un commit propre depuis un travail brouillon. Beaucoup d'utilisateurs le bypasse avec git commit -a, qui indexe et commite d'un coup tous les fichiers modifiés, sans sélection possible.

git add README.md          # indexe un seul fichier
git add -p                 # indexe des morceaux de fichiers
git commit -m "message"   # commite exactement ce qui est indexé

4Une branche = un fichier de 41 octets

Sous Subversion, créer une branche copiait physiquement les fichiers, parfois plusieurs minutes sur un grand projet. Sous Git, c'est un fichier de 41 octets. Le livre l'explique ainsi : « Une branche dans Git est simplement un pointeur léger et déplaçable sur l'un de ces commits » (p. 64). Git écrit ce fichier dans .git/refs/heads/ et c'est tout. À chaque commit, le pointeur avance automatiquement.

# Une branche, c'est littéralement ce fichier :
$ cat .git/refs/heads/main
ca82a6dff817ec66f44342007202690a93763949

git branch feature     # crée un fichier de 41 octets
git checkout feature   # déplace HEAD sur ce fichier

5HEAD : le pointeur qui pointe sur un pointeur

HEAD est un fichier qui contient le nom de votre branche courante (ref: refs/heads/main), qui elle-même pointe vers le dernier commit. Faire un git checkout main met HEAD à jour vers main. Commiter déplace le pointeur de main vers le nouveau commit. HEAD suit automatiquement : Git sait toujours où vous êtes.

C'est le cas où un débutant panique. Si vous faites un git checkout sur un SHA-1 directement, vous entrez en mode detached HEAD : HEAD pointe sur un commit, plus sur une branche.

git checkout 24b9da6      # HEAD se détache : pointe sur un commit, sans branche
# ... vous faites des commits ici : ils ne sont rattachés à RIEN
git switch -c ma-branche   # ✓ on les SAUVE dans une branche avant de partir
# sinon : git switch main → ces commits deviennent orphelins, perdus

Tout commit fait dans cet état existe dans l'historique mais n'est rattaché à aucune branche : il deviendra inaccessible au prochain changement de branche si vous ne créez pas une branche depuis là avant de partir.

6La règle d'or du rebase

Un merge produit un commit de fusion qui marque la jonction de deux branches, visible dans l'historique pour toujours. Le rebase évite ce commit en rejouant vos changements directement sur la branche cible, donnant un historique en ligne droite.

La règle d'or du livre, formulée sans détour : « Ne rebasez pas des commits qui existent en dehors de votre dépôt et sur lesquels d'autres développeurs ont peut-être fondé leur travail. Si vous respectez cette règle, tout ira bien. Sinon, les gens vous haïront, et vos amis et votre famille vous mépriseront. » La raison : rebaser réécrit les hashes SHA-1. Si quelqu'un a basé son travail sur les anciens hashes, forcer un push rebasé crée des historiques contradictoires difficiles à réconcilier.

7Reset démystifié : le modèle des trois arbres

La commande git reset est confuse parce qu'elle fait des choses très différentes selon le flag. Pro Git résout ça avec un modèle : Git gère en permanence trois "arbres" (trois collections de fichiers). Une fois qu'on les comprend, reset devient prévisible.

Les trois arbres : HEAD = le snapshot du dernier commit (ce qui est "enregistré") ; l'Index = le prochain commit en cours de construction (ce qu'on appelle la zone de staging) ; le Working Directory = vos fichiers tels qu'ils sont sur disque, le bac à sable.

Reset opère toujours dans le même ordre : il déplace d'abord HEAD, puis met à jour l'Index, puis met à jour le Working Directory. Il s'arrête là où vous lui dites.

Ce modèle explique des comportements qui semblent arbitraires : git reset HEAD fichier.txt (sans commit cible) dé-stage un fichier parce que reset met l'Index à l'état de HEAD pour ce fichier spécifiquement. git reset --hard est l'unique mode dangereux car c'est le seul qui touche votre Working Directory. « Cette option est la seule façon de rendre la commande reset dangereuse » (p. 262).

8Git est un système de fichiers adressable par contenu

Le chapitre 10 commence par : « Git est fondamentalement un système de fichiers adressable par contenu avec une interface utilisateur de contrôle de version construite par-dessus » (p. 414). Tout ce qui est stocké dans Git (contenu de fichiers, arborescences, commits) est un objet adressé par son hash SHA-1. Le dossier .git/ contient quatre éléments qui comptent vraiment :

• objects/ : la base de données : chaque fichier, arborescence et commit jamais enregistré, indexé par hash
• refs/ : les pointeurs nommés vers des commits (branches, tags, remotes)
• HEAD : la branche sur laquelle vous vous trouvez
• index : la zone de staging : le prochain snapshot en cours de construction

Et ce ne sont pas des abstractions : les commandes de plomberie vous les font toucher du doigt.

git cat-file -p HEAD          # le commit : un tree, un parent, l'auteur, le message
git cat-file -p HEAD^{tree}   # le tree : la liste des fichiers + le hash de chacun
git ls-files --stage         # l'index : ce qui ira dans le prochain commit

C'est tout Git. Tout le reste (branches, merge, rebase) est construit par-dessus ces quatre éléments.