10.2 Les tripes de Git - Les objets de Git

Le prochain type que nous allons étudier est l’arbre (tree) qui résout le problème de stockage du nom du fichier et vous permet d’enregistrer un groupe de fichiers ensemble. Git stocke du contenu de la même manière, mais plus simplement, qu’un système de fichier UNIX. Tout le contenu est stocké comme des objets de type arbre ou blob : un arbre correspondant à un répertoire UNIX et un blob correspond à peu près aux inodes ou au contenu d’un fichier. Un unique arbre contient une ou plusieurs entrées, chacune étant l’empreinte SHA-1 d’un blob ou d’un sous-arbre (sub-tree) avec ses droits d’accès (mode), son type et son nom de fichier associés. L’arbre le plus récent d’un projet pourrait ressembler, par exemple, à ceci :

La syntaxe master^{tree} signifie l’objet arbre qui est pointé par le dernier commit de la branche master. Remarquez que le sous-répertoire lib n’est pas un blob, mais un pointeur vers un autre arbre :

Conceptuellement, les données que Git stocke ressemblent ceci :

Vous pouvez facilement créer votre propre arbre. Git crée habituellement un arbre à partir de l’état de la zone d’attente ou index et écrit une série d’objets arbre à partir de là. Donc, pour créer un objet arbre, vous devez d’abord mettre en place un index en mettant quelques fichiers en attente. Pour créer un index contenant une entrée, la première version de votre fichier test.txt par exemple, utilisons la commande de plomberie update-index. Vous pouvez utiliser cette commande pour ajouter artificiellement une version plus ancienne à une nouvelle zone d’attente. Vous devez utiliser les options --add car le fichier n’existe pas encore dans votre zone d’attente (vous n’avez même pas encore mis en place une zone d’attente) et --cacheinfo car le fichier que vous ajoutez n’est pas dans votre répertoire, mais dans la base de données. Vous pouvez ensuite préciser le mode, SHA-1 et le nom de fichier :

Dans ce cas, vous précisez le mode 100644, qui signifie que c’est un fichier normal. Les alternatives sont 100755, qui signifie que c’est un exécutable, et 120000, qui précise que c’est un lien symbolique. Le concept de « mode » a été repris des mode UNIX, mais est beaucoup moins flexible : ces trois modes sont les seuls valides pour Git, pour les fichiers (blobs) dans Git (bien que d’autres modes soient utilisés pour les répertoires et sous-modules).

Vous pouvez maintenant utiliser la commande write-tree pour écrire la zone d’attente dans un objet arbre. L’option -w est inutile (appeler write-tree crée automatiquement un objet arbre à partir de l’état de l’index si cet arbre n’existe pas) :

Vous pouvez également vérifier que c’est un objet arbre :

Vous allez créer maintenant un nouvel arbre avec la seconde version de test.txt et aussi un nouveau fichier :

Votre zone d’attente contient maintenant la nouvelle version de test.txt ainsi que le nouveau fichier new.txt. Enregistrez cet arbre (c’est-à-dire enregistrez l’état de la zone d’attente ou index dans un objet arbre) et voyez à quoi il ressemble :

Remarquez que cet arbre contient des entrées pour les deux fichiers et que l’empreinte SHA-1 de test.txt est l’empreinte de la « version 2 » de tout à l’heure (1f7a7a). Pour le plaisir, ajoutez le premier arbre à celui-ci, en tant que sous-répertoire. Vous pouvez récupérer un arbre de votre zone d’attente en exécutant read-tree. Dans ce cas, vous pouvez récupérer un arbre existant dans votre zone d’attente comme étant un sous-arbre en utilisant l’option --prefix de read-tree :

Si vous créiez un répertoire de travail à partir du nouvel arbre que vous venez d’enregistrer, vous auriez deux fichiers à la racine du répertoire de travail, ainsi qu’un sous-répertoire appelé bak qui contiendrait la première version du fichier test.txt. Vous pouvez vous représenter les données que Git utilise pour ces structures comme ceci :

Vous avez trois arbres qui définissent différents instantanés du projet que vous suivez, mais le problème précédent persiste : vous devez vous souvenir des valeurs des trois empreintes SHA-1 pour accéder aux instantanés. Vous n’avez pas non plus d’information sur qui a enregistré les instantanés, quand et pourquoi. Ce sont les informations élémentaires qu’un objet commit stocke pour vous.

Pour créer un objet commit, il suffit d’exécuter commit-tree et de préciser l’empreinte SHA-1 d’un seul arbre et quels objets commit, s’il y en a, le précèdent directement. Commencez avec le premier arbre que vous avez créé :

Vous pouvez voir votre nouvel objet commit avec git cat-file :

Le format d’un objet commit est simple : il contient l’arbre racine de l’instantané du projet à ce moment, les informations sur l’auteur et le validateur (qui utilisent vos variables de configuration user.name et user.email et un horodatage); une ligne vide et le message de validation.

Ensuite, vous enregistrez les deux autres objets commit, chacun référençant le commit dont il est issu :

Chacun des trois objets commit pointe sur un des trois arbres d’instantané que vous avez créés. Curieusement, vous disposez maintenant d’un historique Git complet que vous pouvez visualiser avec la commande git log, si vous la lancez sur le SHA-1 du dernier commit :

Fantastique. Vous venez d’effectuer les opérations bas niveau pour construire un historique Git sans avoir utilisé une seule des commandes de haut niveau. C’est l’essence de ce que fait Git quand vous exécutez les commandes git add et git commit. Il stocke les blobs correspondant aux fichiers modifiés, met à jour l’index, écrit les arbres et ajoute les objets commit qui référencent les arbres racines venant juste avant eux. Ces trois objets principaux (le blob, l’arbre et le commit) sont initialement stockés dans des fichiers séparés du répertoire .git/objects. Voici tous les objets contenus dans le répertoire exemple, commentés d’après leur contenu :

Si vous suivez les pointeurs internes de ces objets, vous obtenez un graphe comme celui-ci :

Nous avons parlé plus tôt de l’en-tête présent avec le contenu. Prenons un moment pour étudier la façon dont Git stocke les objets. On verra comment stocker interactivement un objet blob (ici, la chaîne "what is up, doc?") avec le langage Ruby.

Vous pouvez démarrer Ruby en mode interactif avec la commande irb :

Git construit un en-tête qui commence avec le type de l’objet, ici un blob. Ensuite, il ajoute un espace suivi de taille du contenu et enfin un octet nul :

Git concatène l’en-tête avec le contenu original et calcule l’empreinte SHA-1 du nouveau contenu. En Ruby, vous pouvez calculer l’empreinte SHA-1 d’une chaîne en incluant la bibliothèque « digest/SHA-1 » via la commande require, puis en appelant Digest::SHA1.hexdigest() sur la chaîne :

Comparons cela avec la sortie de git hash-object. Ici nous utilisons echo -n pour éviter d’ajouter un retour à la ligne dans l’entrée.

Git compresse le nouveau contenu avec zlib, ce que vous pouvez faire avec la bibliothèque zlib de Ruby. D’abord, vous devez inclure la bibliothèque et ensuite exécuter Zlib::Deflate.deflate() sur le contenu :

Finalement, vous enregistrerez le contenu compressé dans un objet sur le disque. Vous déterminerez le chemin de l’objet que vous voulez enregistrer (les deux premiers caractères de l’empreinte SHA-1 formeront le nom du sous-répertoire et les 38 derniers formeront le nom du fichier dans ce répertoire). En Ruby, on peut utiliser la fonction FileUtils.mkdir_p() pour créer un sous-répertoire s’il n’existe pas. Ensuite, ouvrez le fichier avec File.open() et enregistrez le contenu compressé en appelant la fonction write() sur la référence du fichier :

Vérifions le contenu du fichier au moyen de git cat-file :

C’est tout ! Vous venez juste de créer un objet blob valide.

Tout les objets Git sont stockés de la même façon, mais avec des types différents : l’en-tête commencera par « commit » ou « tree » au lieu de la chaîne « blob ». De plus, alors que le contenu d’un blob peut être à peu près n’importe quoi, le contenu d’un commit ou d’un arbre est formaté de façon très précise.