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 comme 24b9da6552252987aa493b52f8696cd6d3b00373. Modifier le contenu d'un fichier sans que Git le sache est impossible. Git ne fait presque qu'ajouter des données : une fois un commit enregistré, il est quasi indestructible. La seule vraie exception : 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. Si vous faites un git checkout sur un SHA-1 directement au lieu d'un nom de branche, HEAD pointe alors sur un commit sans branche : c'est le mode "detached HEAD" : tout commit fait dans cet état se retrouve sans rattachement, et disparaîtra au prochain changement de branche si vous ne créez pas de branche à partir de là.

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, arborescence de répertoires, 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), refs/ (les pointeurs nommés vers les commits), HEAD (la branche courante), et index (la zone de staging). C'est tout Git.