[{"data":1,"prerenderedAt":830},["ShallowReactive",2],{"/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format":3,"navigation-fr-fr":41,"banner-fr-fr":467,"footer-fr-fr":477,"blog-post-authors-fr-fr-Patrick Steinhardt":715,"blog-related-posts-fr-fr-a-beginners-guide-to-the-git-reftable-format":730,"blog-promotions-fr-fr":767,"next-steps-fr-fr":821},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":25,"description":17,"extension":27,"externalUrl":28,"featured":15,"heroImage":19,"isFeatured":15,"meta":29,"navigation":15,"path":30,"publishedDate":25,"rawbody":31,"seo":32,"slug":14,"stem":37,"tagSlugs":38,"tags":39,"template":13,"updatedDate":26,"__hash__":40},"blogPosts/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format.md","Format reftable de Git : guide pour les débutants",[7],"patrick-steinhardt",[9],"Patrick Steinhardt","Jusqu'à récemment, Git ne pouvait stocker des références qu'au format « fichiers ». Avec la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), Git peut désormais stocker des références au format « reftable ». Ce nouveau format binaire est un peu plus complexe, mais c'est précisément cette complexité qui lui permet de corriger plusieurs lacunes du format « fichiers ». Les objectifs du format « reftable » sont les suivants :\n\n- Rendre la recherche d'une référence unique et l'itération à travers des plages de références aussi efficaces et rapides que possible.\n- Prendre en charge des lectures cohérentes des références afin que Git ne lise jamais un état intermédiaire lorsqu'une mise à jour de plusieurs références n'a été appliquée que partiellement.\n- Prendre en charge des écritures atomiques de sorte que la mise à jour de plusieurs références peut être effectuée comme une opération tout ou rien.\n- Stocker efficacement des références et des journaux de référence (« reflog »).\n\nDans cet article, nous allons examiner le format « reftable » pour comprendre son fonctionnement.\n\n## Stockage des références dans Git\n\nAvant d'entrer dans les détails, récapitulons rapidement la façon dont [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") stockait les références jusqu'à présent. Si le sujet vous est familier, vous pouvez passer cette section.\n\nUn dépôt Git contient deux structures de données importantes :\n\n- [Les objets](https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Les-objets-de-Git), qui contiennent les données réelles de votre dépôt. Ils incluent les validations (« commits »), la structure d'arborescence des répertoires (« tree ») et les blobs qui contiennent votre code source. Les objets sont organisés de manière à ce qu'ils pointent les uns vers les autres, formant ainsi un graphe des objets. En outre, chaque objet est associé à un identifiant unique, appelé ID d'objet.\n\n- Les références, telles que les branches et les étiquettes (« tags »). Ces pointeurs sur des objets du graphe vous permettent de donner des noms à des objets qui sont plus faciles à mémoriser et de suivre les différentes étapes et directions de votre historique de développement. Par exemple, un dépôt peut contenir une branche `main` : il s'agit d'une référence nommée `refs/heads/main` qui pointe vers une validation spécifique.\n\nLes références sont stockées dans la base de données des références. Jusqu'à la version 2.45.0 de Git, le format « fichiers » constituait le seul format de base de données disponible. Ce format stocke chaque référence en tant que fichier normal contenant l'un des éléments suivants :\n\n- Une référence standard qui contient l'ID d'objet de la validation vers laquelle elle pointe.\n- Une référence symbolique qui contient le nom d'une autre référence, de la même manière qu'un lien symbolique pointe vers un autre fichier.\n\nCes références sont régulièrement empaquetées dans un seul fichier `packed-refs` afin de faciliter les recherches.\n\nLes exemples suivants illustrent le fonctionnement du format « fichiers » :\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD is a symbolic reference pointing to refs/heads/main.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main is a regular reference pointing to a commit.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) packs these references into the packed-refs file.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Vue d'ensemble de la structure « reftable »\nSi vous avez installé la version 2.45.0 de Git ou une version plus récente, vous pouvez créer un dépôt au format « reftable » en utilisant l'option `--ref-format=reftable` :\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevant files have been removed for ease of understanding.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nRegardez la configuration du dépôt. Remarquez tout d'abord sa clé de configuration `extension.refstorage` :\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nCette configuration indique à Git que le dépôt a été initialisé avec le format « reftable » et que Git doit utiliser le backend « reftable » pour y accéder.\n\nCurieusement, le dépôt contient encore des fichiers qui semblent utilisés par le backend « fichiers » :\n\n- `HEAD` est une référence symbolique dans Git qui indique généralement la branche sur laquelle vous travaillez actuellement. Bien que le format « reftable » n'utilise pas HEAD, la présence de cette référence est nécessaire pour qu'un répertoire soit reconnu comme un dépôt Git par les clients Git. Par conséquent, lorsque vous utilisez le format « reftable », `HEAD` est juste une entité fictive et temporaire dont le contenu est `ref: refs/heads/.invalid`.\n\n- `refs/head` est un fichier dont le contenu est : `this repository uses the reftable format`. Les clients Git qui ne connaissent pas le format « reftable » s'attendent généralement à ce que le chemin d'accès soit un répertoire. Par conséquent, la création de ce chemin d'accès en tant que fichier entraîne intentionnellement l'échec des anciens clients Git s'ils tentent d'accéder au dépôt par le biais du backend « fichiers ».\n\nLes références réelles sont stockées dans le répertoire `reftable/` :\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nIl y a ici deux fichiers :\n\n- `0x000000000001-0x000000000001-794bd722.ref` est une table contenant des références et des données de reflog dans un format binaire.\n\n- `tables.list` est, comme son nom l'indique, une liste de tables. Dans l'état actuel du dépôt, le fichier contient une seule ligne, qui est le nom de la table. Ce fichier suit l'ensemble actuel des tables actives dans la base de données « reftable ». Il est mis à jour chaque fois que de nouvelles tables sont ajoutées au dépôt.\n\nLa mise à jour d'une référence crée une nouvelle table :\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nComme vous pouvez le constater, la table précédente a été remplacée par une nouvelle. En outre, le fichier `tables.list` a été mis à jour pour contenir la nouvelle table.\n\n## Structure d'une table\n\nComme mentionné précédemment, les données réelles de la base de données des références sont contenues dans des tables. Pour faire simple, une table se divise en plusieurs sections :\n\n- L'en-tête contient des métadonnées sur la table. En plus d'autres informations, il inclut la version du format, la taille des blocs de données et la fonction de hachage utilisée par le dépôt (par exemple, SHA1 ou SHA256).\n- La section « ref » contient vos références. Ces enregistrements ont une clé identique au nom de la référence et pointent soit vers un ID d'objet pour les références standards, soit vers une autre référence pour les références symboliques.\n- La section « obj » contient la correspondance inverse entre les ID d'objet et les références qui pointent vers eux. Celle-ci permet à Git de rechercher efficacement les références qui pointent vers un ID d'objet spécifique.\n- La section « log » contient vos éléments reflog. Ces enregistrements ont une clé identique au nom de la référence, plus un index qui représente le numéro de l'élément du journal. Ils contiennent en outre les anciens et nouveaux ID d'objet, ainsi que le message pour cet élément reflog.\n- Le « footer » contient des offsets pour les différentes sections.\n\n![table longue avec toutes les sections reftable](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nChaque type de section est structuré de manière similaire. Les sections contiennent un ensemble d'enregistrements qui sont classés en fonction de la clé de chaque enregistrement. Par exemple, lorsque vous avez ces deux enregistrements de références : `refs/heads/aaaaa` et `refs/heads/bbb`, vous avez deux enregistrements de références dont les noms de référence sont les clés respectives, et `refs/heads/aaaaa` vient avant `refs/heads/bbb`.\n\nChaque section est par ailleurs divisée en blocs d'une longueur fixe. La longueur d'un bloc est encodée dans l'en-tête et remplit deux fonctions :\n\n- En se basant sur le début de la section ainsi que la taille des blocs de données, le processus qui lit les tables sait implicitement où chacun des blocs commence. Git peut ainsi facilement effectuer une recherche au milieu d'une section sans lire les blocs précédents, ce qui permet d'effectuer des recherches par dichotomie sur des blocs pour accélérer la recherche d'enregistrements.\n- Elle permet au processus qui lit les tables de savoir combien de données lire sur le disque à la fois. Par conséquent, la taille des blocs de données est par défaut définie à 4 KiB, ce qui correspond à la taille de secteur la plus courante pour les disques durs. La taille maximale des blocs de données est de 16 Mo.\n\nIntéressons-nous à une section « ref » : elle ressemble à peu près au graphique suivant. Notez comment ses enregistrements sont ordonnés lexicographiquement à l'intérieur des blocs, mais aussi entre différents blocs.\n\n![bloc de référence non compressé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMaintenant que vous disposez de ces informations, vous pouvez localiser un enregistrement en suivant les étapes suivantes :\n\n1. Effectuez une recherche par dichotomie sur les blocs en regardant les clés de leurs premiers enregistrements respectifs, ce qui permet d'identifier le bloc qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche linéaire sur les enregistrements de ce bloc.\n\nCes deux étapes sont encore quelque peu inefficaces. S'il y a beaucoup de blocs, vous devrez peut-être effectuer une lecture logarithmique d'un bon nombre d'entre eux au cours de la recherche par dichotomie pour trouver celui que vous recherchez. Et lorsque les blocs contiennent de nombreux enregistrements, une recherche linéaire doit potentiellement tous les lire.\n\nLe format « reftable » intègre des mécanismes supplémentaires pour résoudre ces problèmes de performance. Nous les mentionnerons dans les prochaines sections.\n\n### Compression de préfixe\n\nComme vous l'avez peut-être remarqué, toutes les clés d'enregistrement partagent le même préfixe `refs/`. C'est une norme établie dans Git :\n\n- Toutes les branches commencent par `refs/heads/`.\n- Toutes les étiquettes (« tags ») commencent par `refs/tags/`.\n\nPar conséquent, il est très probable que les enregistrements suivants partagent une partie importante du préfixe de leur clé. C'est une bonne occasion d'économiser de l'espace de stockage précieux. Comme nous savons que la plupart des clés partagent un préfixe commun, il est logique d'utiliser ce dernier à des fins d'optimisation.\n\nCelle-ci passe par la compression de préfixe. Chaque enregistrement encode une longueur de préfixe qui indique au processus qui lit les tables le nombre d'octets à réutiliser à partir de la clé de l'enregistrement précédent. Si vous avez deux enregistrements, `refs/heads/a` et `refs/heads/b`, ce dernier peut être encodé en spécifiant une longueur de préfixe de 11, puis en stockant uniquement le suffixe `b`. Le processus qui lit les tables prendra alors les 11 premiers octets de `refs/heads/a`, c'est-à-dire `refs/heads/`, et y ajoutera le suffixe `b`.\n\n![compression de préfixe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### « Restart points »\n\nComme expliqué précédemment et d'après vos connaissances actuelles du format « reftable », une recherche linéaire constitue la meilleure façon de chercher une référence dans un bloc, car la longueur des enregistrements n'est pas fixe. Il est donc impossible de savoir où les enregistrements devraient commencer sans parcourir l'intégralité du bloc depuis le début. En outre, même si les enregistrements étaient de longueur fixe, il ne serait pas possible de rechercher au milieu d'un bloc, car la compression de préfixe nous oblige également à lire les enregistrements précédents.\n\nUne recherche linéaire serait assez inefficace, dans la mesure où les blocs peuvent contenir des centaines, voire des milliers d'enregistrements. Pour résoudre ce problème, le format « reftable » encode des « restart points » dans chaque bloc. Les « restart points » sont des enregistrements non compressés où la compression de préfixe est réinitialisée. Par conséquent, les enregistrements des « restart points » contiennent toujours leur clé complète. Il devient donc possible de rechercher et de lire directement l'enregistrement, sans avoir à lire les enregistrements précédents. Ces « restart points » sont répertoriés dans le footer de chaque bloc.\n\nGrâce à ces informations, vous pouvez maintenant éviter d'effectuer une recherche linéaire sur le bloc. Effectuez plutôt une recherche par dichotomie sur les « restart points » en cherchant le premier « restart point » dont la clé est lexicographiquement supérieure à la clé recherchée. Il s'ensuit que l'enregistrement que vous recherchez doit être situé dans la section s'étendant entre le « restart point » _précédent_ et celui identifié.\n\nLa procédure initiale pour rechercher un enregistrement (recherche par dichotomie du bloc, recherche linéaire de l'enregistrement) est donc la suivante :\n\n1. Effectuez une recherche par dichotomie sur les blocs, pour identifier celui qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche par dichotomie sur les « restart points », en identifiant la sous-section du bloc qui doit contenir l'enregistrement.\n\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n![Recherche linéaire pour un enregistrement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Index\n\nBien que la recherche d'enregistrements à l'intérieur d'un bloc soit désormais raisonnablement efficace, ce n'est pas le cas pour l'identification du bloc spécifique. Une recherche par dichotomie peut être relativement performante sur quelques blocs, mais les dépôts contenant des millions de références peuvent comporter des centaines, voire des milliers de blocs. En l'absence d'une structure de données supplémentaire visant à minimiser les accès au disque, chaque recherche de bloc pourrait entraîner en moyenne un nombre important d'accès au disque.\n\nPour éviter cette situation, chaque section peut être suivie d'une section d'indexation qui fournit un moyen efficace de rechercher un bloc. Chaque enregistrement d'index contient les informations suivantes :\n\n- L'emplacement du bloc qu'il indexe.\n- La clé du dernier enregistrement du bloc qu'il indexe.\n\nPour trois blocs ou moins, une recherche par dichotomie nécessite toujours, au plus, deux lectures de disque pour trouver le bloc cible souhaité. Le nombre de lectures est le même pour un index : une pour lire l'index et une pour lire le bloc souhaité. Par conséquent, les index ne sont écrits que lorsqu'ils évitent de fait plusieurs lectures, ce qui est le cas lorsque quatre blocs ou plus sont indexés.\n\nLa question se pose alors de savoir ce qu'il se passe lorsque l'index lui-même devient si grand qu'il s'étend sur plusieurs blocs. Vous l'avez peut-être deviné : nous écrivons un nouvel index qui indexe l'index. Ces index à plusieurs niveaux ne deviennent vraiment nécessaires que lorsque vos dépôts contiennent des centaines de milliers de références.\n\nÀ l'aide de ces index, vous pouvez désormais accélérer la recherche d'enregistrements :\n1. Déterminez s'il existe un index en consultant le footer de la table.\n\t- Si c'est le cas, effectuez une recherche par dichotomie dans l'index pour trouver le bloc souhaité. Ce bloc peut pointer vers un bloc d'index, auquel cas il vous faut répéter l'opération jusqu'à atteindre un enregistrement du type souhaité.\n\t- Dans le cas contraire, effectuez une recherche par dichotomie dans les blocs comme auparavant.\n2. Effectuez une recherche par dichotomie sur les « restart points » pour identifier la sous-section du bloc qui doit contenir l'enregistrement.\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n## Tables multiples\n\nJusqu'à présent, nous n'avons discuté que de la façon de lire une table _unique_. Comme l'indique le nom `tables.list`, votre base de données « reftable » peut contenir une liste de tables.\n\nChaque fois que vous mettez à jour une référence dans votre dépôt, une nouvelle table est créée et ajoutée à `tables.list`. Vous obtiendrez donc plusieurs tables, comme suit :\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\nLa lecture de l'état réel d'un dépôt nous oblige à fusionner ces multiples tables en une seule table virtuelle.\n\nVous vous demandez peut-être comment le format « reftable » connaît la valeur la plus récente d'une référence donnée, si une table est créée pour chaque mise à jour de référence et que la même référence est mise à jour plusieurs fois. Intuitivement, on pourrait supposer que la valeur serait celle de la table la plus récente contenant la référence.\n\nEn réalité, chaque enregistrement a un index de mise à jour qui encode la « priorisation » d'un enregistrement. Par exemple, s'il existe deux enregistrements pour le même nom de référence, celui qui a l'index de mise à jour le plus élevé remplace celui qui a l'index de mise à jour le plus bas.\n\nCes index de mise à jour sont visibles dans la structure de fichiers ci-dessus. Les longues chaînes hexagonales (par exemple `0x000000000001`) sont les index de mise à jour. L'index de mise à jour minimum contenu dans la table se trouve dans la partie gauche de son nom de fichier et l'index de mise à jour maximum dans la partie droite.\n\nLe merge des tables se fait ensuite via une [file d'attente de priorisation](https://fr.wikipedia.org/wiki/File_de_priorit%C3%A9) qui est triée par clé d’enregistrement ainsi que son index de mise à jour. Imaginez que vous voulez parcourir tous les enregistrements de références. Vous devez suivre les étapes suivantes :\n\n1. Pour chaque table, ajoutez son premier enregistrement à la file d'attente de priorisation.\n\n![Ajout du premier enregistrement à la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Récupérez et retirez de la file d'attente l'enregistrement en tête de la file. Comme la file d'attente est triée par index de mise à jour, cet enregistrement doit être la version la plus récente. Ajoutez l'enregistrement suivant de la table de cet enregistrement à la file d'attente de priorisation.\n\n![Définition de la tête de la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Retirez tous les enregistrements de la file d'attente qui ont la même clé que l’enregistrement récupéré. Ces enregistrements sont dépassés et ne seront pas utilisés. Pour chaque table pour laquelle vous supprimez des enregistrements, ajoutez l'enregistrement suivant à la file d'attente de priorisation.\n\n![Dépôt de tous les enregistrements de la file qui ont le même nom](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\nVous pouvez maintenant répéter les étapes ci-dessus pour lire les enregistrements pour d'autres clés.\n\nLes tables peuvent contenir des enregistrements spéciaux « tombstone » qui marquent un enregistrement supprimé. Vous pouvez ainsi supprimer des enregistrements sans avoir à réécrire toutes les tables afin qu'elles ne contiennent plus ces enregistrements.\n\n### Compactage automatique\n\nLa file d'attente de priorisation a beau être un concept simple, elle ne parviendrait pas à fusionner efficacement des centaines de tables, ni même des dizaines. S'il est vrai que chaque mise à jour de vos références ajoute une nouvelle table à votre fichier `tables.list`, ce n'est pas tout.\n\nLe compactage automatique entre ici en scène : lorsqu'une nouvelle table a été ajoutée à la liste des tables, le backend « reftable » vérifie si certaines des tables doivent être fusionnées. Ce processus utilise une méthode simple : nous vérifions que les tailles de fichiers de la liste des tables forment une [séquence géométrique](https://en.wikipedia.org/wiki/Geometric_progression). Chaque table `n` doit être au moins deux fois plus grande que la table suivante la plus récente `n + 1`. Si cette séquence géométrique n'est pas respectée, le backend compacte les tables afin de restaurer la séquence géométrique.\n\nCe processus aboutit à des structures de ce type :\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nNotez que la propriété `size(n) > size(n+1) * 2` est respectée pour chaque table.\n\nL'une des conséquences du compactage automatique est la maintenance automatique du backend « reftable ». Il n'est plus nécessaire d'exécuter `git pack-refs` dans un dépôt.\n\n## Vous souhaitez en savoir plus ?\n\nÀ présent, le fonctionnement du nouveau format « reftable » ne devrait plus avoir de secret pour vous. Si vous souhaitez approfondir vos connaissances, vous pouvez consulter la [documentation technique](https://git-scm.com/docs/reftable) fournie par le projet Git.\n\n> Lisez notre [récapitulatif sur Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/), [Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/ \"Nouveautés Git 2.46.0\") et Git [2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/ \"Nouveautés Git 2.47.0\") pour découvrir les autres points forts de cette version.","open-source",{"template":13,"slug":14,"featured":15},"BlogPost","a-beginners-guide-to-the-git-reftable-format",true,{"title":5,"description":17,"authors":18,"heroImage":19,"tags":20,"category":11,"date":25,"updatedDate":26,"body":10},"Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable », révolutionnant ainsi le stockage des références. Découvrez en détail le fonctionnement de ce nouveau format.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png",[21,22,23,24],"git","tutorial","open source","performance","2024-05-30","2024-12-19","md",null,{},"/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format","---\nseo:\n  title: 'Format reftable de Git : guide pour les débutants'\n  description: >-\n    Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable »,\n    révolutionnant ainsi le stockage des références. Découvrez en détail le\n    fonctionnement de ce nouveau format.\n  ogTitle: 'Format reftable de Git : guide pour les débutants'\n  ogDescription: >-\n    Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable »,\n    révolutionnant ainsi le stockage des références. Découvrez en détail le\n    fonctionnement de ce nouveau format.\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png\n  ogUrl: https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format\ntitle: 'Format reftable de Git : guide pour les débutants'\ndescription: Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable », révolutionnant ainsi le stockage des références. Découvrez en détail le fonctionnement de ce nouveau format.\nauthors:\n  - Patrick Steinhardt\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png\ntags:\n  - git\n  - tutorial\n  - open source\n  - performance\ncategory: open-source\ndate: '2024-05-30'\nupdatedDate: '2024-12-19'\nslug: a-beginners-guide-to-the-git-reftable-format\nfeatured: true\ntemplate: BlogPost\n---\n\nJusqu'à récemment, Git ne pouvait stocker des références qu'au format « fichiers ». Avec la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), Git peut désormais stocker des références au format « reftable ». Ce nouveau format binaire est un peu plus complexe, mais c'est précisément cette complexité qui lui permet de corriger plusieurs lacunes du format « fichiers ». Les objectifs du format « reftable » sont les suivants :\n\n- Rendre la recherche d'une référence unique et l'itération à travers des plages de références aussi efficaces et rapides que possible.\n- Prendre en charge des lectures cohérentes des références afin que Git ne lise jamais un état intermédiaire lorsqu'une mise à jour de plusieurs références n'a été appliquée que partiellement.\n- Prendre en charge des écritures atomiques de sorte que la mise à jour de plusieurs références peut être effectuée comme une opération tout ou rien.\n- Stocker efficacement des références et des journaux de référence (« reflog »).\n\nDans cet article, nous allons examiner le format « reftable » pour comprendre son fonctionnement.\n\n## Stockage des références dans Git\n\nAvant d'entrer dans les détails, récapitulons rapidement la façon dont [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") stockait les références jusqu'à présent. Si le sujet vous est familier, vous pouvez passer cette section.\n\nUn dépôt Git contient deux structures de données importantes :\n\n- [Les objets](https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Les-objets-de-Git), qui contiennent les données réelles de votre dépôt. Ils incluent les validations (« commits »), la structure d'arborescence des répertoires (« tree ») et les blobs qui contiennent votre code source. Les objets sont organisés de manière à ce qu'ils pointent les uns vers les autres, formant ainsi un graphe des objets. En outre, chaque objet est associé à un identifiant unique, appelé ID d'objet.\n\n- Les références, telles que les branches et les étiquettes (« tags »). Ces pointeurs sur des objets du graphe vous permettent de donner des noms à des objets qui sont plus faciles à mémoriser et de suivre les différentes étapes et directions de votre historique de développement. Par exemple, un dépôt peut contenir une branche `main` : il s'agit d'une référence nommée `refs/heads/main` qui pointe vers une validation spécifique.\n\nLes références sont stockées dans la base de données des références. Jusqu'à la version 2.45.0 de Git, le format « fichiers » constituait le seul format de base de données disponible. Ce format stocke chaque référence en tant que fichier normal contenant l'un des éléments suivants :\n\n- Une référence standard qui contient l'ID d'objet de la validation vers laquelle elle pointe.\n- Une référence symbolique qui contient le nom d'une autre référence, de la même manière qu'un lien symbolique pointe vers un autre fichier.\n\nCes références sont régulièrement empaquetées dans un seul fichier `packed-refs` afin de faciliter les recherches.\n\nLes exemples suivants illustrent le fonctionnement du format « fichiers » :\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD is a symbolic reference pointing to refs/heads/main.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main is a regular reference pointing to a commit.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) packs these references into the packed-refs file.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Vue d'ensemble de la structure « reftable »\nSi vous avez installé la version 2.45.0 de Git ou une version plus récente, vous pouvez créer un dépôt au format « reftable » en utilisant l'option `--ref-format=reftable` :\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevant files have been removed for ease of understanding.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nRegardez la configuration du dépôt. Remarquez tout d'abord sa clé de configuration `extension.refstorage` :\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nCette configuration indique à Git que le dépôt a été initialisé avec le format « reftable » et que Git doit utiliser le backend « reftable » pour y accéder.\n\nCurieusement, le dépôt contient encore des fichiers qui semblent utilisés par le backend « fichiers » :\n\n- `HEAD` est une référence symbolique dans Git qui indique généralement la branche sur laquelle vous travaillez actuellement. Bien que le format « reftable » n'utilise pas HEAD, la présence de cette référence est nécessaire pour qu'un répertoire soit reconnu comme un dépôt Git par les clients Git. Par conséquent, lorsque vous utilisez le format « reftable », `HEAD` est juste une entité fictive et temporaire dont le contenu est `ref: refs/heads/.invalid`.\n\n- `refs/head` est un fichier dont le contenu est : `this repository uses the reftable format`. Les clients Git qui ne connaissent pas le format « reftable » s'attendent généralement à ce que le chemin d'accès soit un répertoire. Par conséquent, la création de ce chemin d'accès en tant que fichier entraîne intentionnellement l'échec des anciens clients Git s'ils tentent d'accéder au dépôt par le biais du backend « fichiers ».\n\nLes références réelles sont stockées dans le répertoire `reftable/` :\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nIl y a ici deux fichiers :\n\n- `0x000000000001-0x000000000001-794bd722.ref` est une table contenant des références et des données de reflog dans un format binaire.\n\n- `tables.list` est, comme son nom l'indique, une liste de tables. Dans l'état actuel du dépôt, le fichier contient une seule ligne, qui est le nom de la table. Ce fichier suit l'ensemble actuel des tables actives dans la base de données « reftable ». Il est mis à jour chaque fois que de nouvelles tables sont ajoutées au dépôt.\n\nLa mise à jour d'une référence crée une nouvelle table :\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nComme vous pouvez le constater, la table précédente a été remplacée par une nouvelle. En outre, le fichier `tables.list` a été mis à jour pour contenir la nouvelle table.\n\n## Structure d'une table\n\nComme mentionné précédemment, les données réelles de la base de données des références sont contenues dans des tables. Pour faire simple, une table se divise en plusieurs sections :\n\n- L'en-tête contient des métadonnées sur la table. En plus d'autres informations, il inclut la version du format, la taille des blocs de données et la fonction de hachage utilisée par le dépôt (par exemple, SHA1 ou SHA256).\n- La section « ref » contient vos références. Ces enregistrements ont une clé identique au nom de la référence et pointent soit vers un ID d'objet pour les références standards, soit vers une autre référence pour les références symboliques.\n- La section « obj » contient la correspondance inverse entre les ID d'objet et les références qui pointent vers eux. Celle-ci permet à Git de rechercher efficacement les références qui pointent vers un ID d'objet spécifique.\n- La section « log » contient vos éléments reflog. Ces enregistrements ont une clé identique au nom de la référence, plus un index qui représente le numéro de l'élément du journal. Ils contiennent en outre les anciens et nouveaux ID d'objet, ainsi que le message pour cet élément reflog.\n- Le « footer » contient des offsets pour les différentes sections.\n\n![table longue avec toutes les sections reftable](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nChaque type de section est structuré de manière similaire. Les sections contiennent un ensemble d'enregistrements qui sont classés en fonction de la clé de chaque enregistrement. Par exemple, lorsque vous avez ces deux enregistrements de références : `refs/heads/aaaaa` et `refs/heads/bbb`, vous avez deux enregistrements de références dont les noms de référence sont les clés respectives, et `refs/heads/aaaaa` vient avant `refs/heads/bbb`.\n\nChaque section est par ailleurs divisée en blocs d'une longueur fixe. La longueur d'un bloc est encodée dans l'en-tête et remplit deux fonctions :\n\n- En se basant sur le début de la section ainsi que la taille des blocs de données, le processus qui lit les tables sait implicitement où chacun des blocs commence. Git peut ainsi facilement effectuer une recherche au milieu d'une section sans lire les blocs précédents, ce qui permet d'effectuer des recherches par dichotomie sur des blocs pour accélérer la recherche d'enregistrements.\n- Elle permet au processus qui lit les tables de savoir combien de données lire sur le disque à la fois. Par conséquent, la taille des blocs de données est par défaut définie à 4 KiB, ce qui correspond à la taille de secteur la plus courante pour les disques durs. La taille maximale des blocs de données est de 16 Mo.\n\nIntéressons-nous à une section « ref » : elle ressemble à peu près au graphique suivant. Notez comment ses enregistrements sont ordonnés lexicographiquement à l'intérieur des blocs, mais aussi entre différents blocs.\n\n![bloc de référence non compressé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMaintenant que vous disposez de ces informations, vous pouvez localiser un enregistrement en suivant les étapes suivantes :\n\n1. Effectuez une recherche par dichotomie sur les blocs en regardant les clés de leurs premiers enregistrements respectifs, ce qui permet d'identifier le bloc qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche linéaire sur les enregistrements de ce bloc.\n\nCes deux étapes sont encore quelque peu inefficaces. S'il y a beaucoup de blocs, vous devrez peut-être effectuer une lecture logarithmique d'un bon nombre d'entre eux au cours de la recherche par dichotomie pour trouver celui que vous recherchez. Et lorsque les blocs contiennent de nombreux enregistrements, une recherche linéaire doit potentiellement tous les lire.\n\nLe format « reftable » intègre des mécanismes supplémentaires pour résoudre ces problèmes de performance. Nous les mentionnerons dans les prochaines sections.\n\n### Compression de préfixe\n\nComme vous l'avez peut-être remarqué, toutes les clés d'enregistrement partagent le même préfixe `refs/`. C'est une norme établie dans Git :\n\n- Toutes les branches commencent par `refs/heads/`.\n- Toutes les étiquettes (« tags ») commencent par `refs/tags/`.\n\nPar conséquent, il est très probable que les enregistrements suivants partagent une partie importante du préfixe de leur clé. C'est une bonne occasion d'économiser de l'espace de stockage précieux. Comme nous savons que la plupart des clés partagent un préfixe commun, il est logique d'utiliser ce dernier à des fins d'optimisation.\n\nCelle-ci passe par la compression de préfixe. Chaque enregistrement encode une longueur de préfixe qui indique au processus qui lit les tables le nombre d'octets à réutiliser à partir de la clé de l'enregistrement précédent. Si vous avez deux enregistrements, `refs/heads/a` et `refs/heads/b`, ce dernier peut être encodé en spécifiant une longueur de préfixe de 11, puis en stockant uniquement le suffixe `b`. Le processus qui lit les tables prendra alors les 11 premiers octets de `refs/heads/a`, c'est-à-dire `refs/heads/`, et y ajoutera le suffixe `b`.\n\n![compression de préfixe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### « Restart points »\n\nComme expliqué précédemment et d'après vos connaissances actuelles du format « reftable », une recherche linéaire constitue la meilleure façon de chercher une référence dans un bloc, car la longueur des enregistrements n'est pas fixe. Il est donc impossible de savoir où les enregistrements devraient commencer sans parcourir l'intégralité du bloc depuis le début. En outre, même si les enregistrements étaient de longueur fixe, il ne serait pas possible de rechercher au milieu d'un bloc, car la compression de préfixe nous oblige également à lire les enregistrements précédents.\n\nUne recherche linéaire serait assez inefficace, dans la mesure où les blocs peuvent contenir des centaines, voire des milliers d'enregistrements. Pour résoudre ce problème, le format « reftable » encode des « restart points » dans chaque bloc. Les « restart points » sont des enregistrements non compressés où la compression de préfixe est réinitialisée. Par conséquent, les enregistrements des « restart points » contiennent toujours leur clé complète. Il devient donc possible de rechercher et de lire directement l'enregistrement, sans avoir à lire les enregistrements précédents. Ces « restart points » sont répertoriés dans le footer de chaque bloc.\n\nGrâce à ces informations, vous pouvez maintenant éviter d'effectuer une recherche linéaire sur le bloc. Effectuez plutôt une recherche par dichotomie sur les « restart points » en cherchant le premier « restart point » dont la clé est lexicographiquement supérieure à la clé recherchée. Il s'ensuit que l'enregistrement que vous recherchez doit être situé dans la section s'étendant entre le « restart point » _précédent_ et celui identifié.\n\nLa procédure initiale pour rechercher un enregistrement (recherche par dichotomie du bloc, recherche linéaire de l'enregistrement) est donc la suivante :\n\n1. Effectuez une recherche par dichotomie sur les blocs, pour identifier celui qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche par dichotomie sur les « restart points », en identifiant la sous-section du bloc qui doit contenir l'enregistrement.\n\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n![Recherche linéaire pour un enregistrement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Index\n\nBien que la recherche d'enregistrements à l'intérieur d'un bloc soit désormais raisonnablement efficace, ce n'est pas le cas pour l'identification du bloc spécifique. Une recherche par dichotomie peut être relativement performante sur quelques blocs, mais les dépôts contenant des millions de références peuvent comporter des centaines, voire des milliers de blocs. En l'absence d'une structure de données supplémentaire visant à minimiser les accès au disque, chaque recherche de bloc pourrait entraîner en moyenne un nombre important d'accès au disque.\n\nPour éviter cette situation, chaque section peut être suivie d'une section d'indexation qui fournit un moyen efficace de rechercher un bloc. Chaque enregistrement d'index contient les informations suivantes :\n\n- L'emplacement du bloc qu'il indexe.\n- La clé du dernier enregistrement du bloc qu'il indexe.\n\nPour trois blocs ou moins, une recherche par dichotomie nécessite toujours, au plus, deux lectures de disque pour trouver le bloc cible souhaité. Le nombre de lectures est le même pour un index : une pour lire l'index et une pour lire le bloc souhaité. Par conséquent, les index ne sont écrits que lorsqu'ils évitent de fait plusieurs lectures, ce qui est le cas lorsque quatre blocs ou plus sont indexés.\n\nLa question se pose alors de savoir ce qu'il se passe lorsque l'index lui-même devient si grand qu'il s'étend sur plusieurs blocs. Vous l'avez peut-être deviné : nous écrivons un nouvel index qui indexe l'index. Ces index à plusieurs niveaux ne deviennent vraiment nécessaires que lorsque vos dépôts contiennent des centaines de milliers de références.\n\nÀ l'aide de ces index, vous pouvez désormais accélérer la recherche d'enregistrements :\n1. Déterminez s'il existe un index en consultant le footer de la table.\n\t- Si c'est le cas, effectuez une recherche par dichotomie dans l'index pour trouver le bloc souhaité. Ce bloc peut pointer vers un bloc d'index, auquel cas il vous faut répéter l'opération jusqu'à atteindre un enregistrement du type souhaité.\n\t- Dans le cas contraire, effectuez une recherche par dichotomie dans les blocs comme auparavant.\n2. Effectuez une recherche par dichotomie sur les « restart points » pour identifier la sous-section du bloc qui doit contenir l'enregistrement.\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n## Tables multiples\n\nJusqu'à présent, nous n'avons discuté que de la façon de lire une table _unique_. Comme l'indique le nom `tables.list`, votre base de données « reftable » peut contenir une liste de tables.\n\nChaque fois que vous mettez à jour une référence dans votre dépôt, une nouvelle table est créée et ajoutée à `tables.list`. Vous obtiendrez donc plusieurs tables, comme suit :\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\nLa lecture de l'état réel d'un dépôt nous oblige à fusionner ces multiples tables en une seule table virtuelle.\n\nVous vous demandez peut-être comment le format « reftable » connaît la valeur la plus récente d'une référence donnée, si une table est créée pour chaque mise à jour de référence et que la même référence est mise à jour plusieurs fois. Intuitivement, on pourrait supposer que la valeur serait celle de la table la plus récente contenant la référence.\n\nEn réalité, chaque enregistrement a un index de mise à jour qui encode la « priorisation » d'un enregistrement. Par exemple, s'il existe deux enregistrements pour le même nom de référence, celui qui a l'index de mise à jour le plus élevé remplace celui qui a l'index de mise à jour le plus bas.\n\nCes index de mise à jour sont visibles dans la structure de fichiers ci-dessus. Les longues chaînes hexagonales (par exemple `0x000000000001`) sont les index de mise à jour. L'index de mise à jour minimum contenu dans la table se trouve dans la partie gauche de son nom de fichier et l'index de mise à jour maximum dans la partie droite.\n\nLe merge des tables se fait ensuite via une [file d'attente de priorisation](https://fr.wikipedia.org/wiki/File_de_priorit%C3%A9) qui est triée par clé d’enregistrement ainsi que son index de mise à jour. Imaginez que vous voulez parcourir tous les enregistrements de références. Vous devez suivre les étapes suivantes :\n\n1. Pour chaque table, ajoutez son premier enregistrement à la file d'attente de priorisation.\n\n![Ajout du premier enregistrement à la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Récupérez et retirez de la file d'attente l'enregistrement en tête de la file. Comme la file d'attente est triée par index de mise à jour, cet enregistrement doit être la version la plus récente. Ajoutez l'enregistrement suivant de la table de cet enregistrement à la file d'attente de priorisation.\n\n![Définition de la tête de la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Retirez tous les enregistrements de la file d'attente qui ont la même clé que l’enregistrement récupéré. Ces enregistrements sont dépassés et ne seront pas utilisés. Pour chaque table pour laquelle vous supprimez des enregistrements, ajoutez l'enregistrement suivant à la file d'attente de priorisation.\n\n![Dépôt de tous les enregistrements de la file qui ont le même nom](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\nVous pouvez maintenant répéter les étapes ci-dessus pour lire les enregistrements pour d'autres clés.\n\nLes tables peuvent contenir des enregistrements spéciaux « tombstone » qui marquent un enregistrement supprimé. Vous pouvez ainsi supprimer des enregistrements sans avoir à réécrire toutes les tables afin qu'elles ne contiennent plus ces enregistrements.\n\n### Compactage automatique\n\nLa file d'attente de priorisation a beau être un concept simple, elle ne parviendrait pas à fusionner efficacement des centaines de tables, ni même des dizaines. S'il est vrai que chaque mise à jour de vos références ajoute une nouvelle table à votre fichier `tables.list`, ce n'est pas tout.\n\nLe compactage automatique entre ici en scène : lorsqu'une nouvelle table a été ajoutée à la liste des tables, le backend « reftable » vérifie si certaines des tables doivent être fusionnées. Ce processus utilise une méthode simple : nous vérifions que les tailles de fichiers de la liste des tables forment une [séquence géométrique](https://en.wikipedia.org/wiki/Geometric_progression). Chaque table `n` doit être au moins deux fois plus grande que la table suivante la plus récente `n + 1`. Si cette séquence géométrique n'est pas respectée, le backend compacte les tables afin de restaurer la séquence géométrique.\n\nCe processus aboutit à des structures de ce type :\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nNotez que la propriété `size(n) > size(n+1) * 2` est respectée pour chaque table.\n\nL'une des conséquences du compactage automatique est la maintenance automatique du backend « reftable ». Il n'est plus nécessaire d'exécuter `git pack-refs` dans un dépôt.\n\n## Vous souhaitez en savoir plus ?\n\nÀ présent, le fonctionnement du nouveau format « reftable » ne devrait plus avoir de secret pour vous. Si vous souhaitez approfondir vos connaissances, vous pouvez consulter la [documentation technique](https://git-scm.com/docs/reftable) fournie par le projet Git.\n\n> Lisez notre [récapitulatif sur Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/), [Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/ \"Nouveautés Git 2.46.0\") et Git [2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/ \"Nouveautés Git 2.47.0\") pour découvrir les autres points forts de cette version.\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":33,"ogImage":19,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},false,"https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","https://about.gitlab.com","article","fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",[21,22,11,24],[21,22,23,24],"IUfhPws5ABgMfKrd7Y_ZNCXrsj9BH5iaahyC18rjOg0",{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":383,"minimal":418,"duo":437,"switchNav":446,"pricingDeployment":457},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/fr-fr/","gitlab logo","header",{"text":48,"config":49},"Commencer un essai gratuit",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Contacter l'équipe commerciale",{"href":55,"dataGaName":56,"dataGaLocation":46},"/fr-fr/sales/","sales",{"text":58,"config":59},"Connexion",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,92,194,199,302,363],{"text":64,"config":65,"menu":67},"Plateforme",{"dataNavLevelOne":66},"platform",{"type":68,"columns":69},"cards",[70,76,84],{"title":64,"description":71,"link":72},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":73,"config":74},"Explorer notre plateforme",{"href":75,"dataGaName":66,"dataGaLocation":46},"/fr-fr/platform/",{"title":77,"description":78,"link":79},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":80,"config":81},"Découvrir GitLab Duo",{"href":82,"dataGaName":83,"dataGaLocation":46},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":85,"description":86,"link":87},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":88,"config":89},"En savoir plus",{"href":90,"dataGaName":91,"dataGaLocation":46},"/fr-fr/why-gitlab/","why gitlab",{"text":93,"left":15,"config":94,"menu":96},"Produit",{"dataNavLevelOne":95},"solutions",{"type":97,"link":98,"columns":102,"feature":173},"lists",{"text":99,"config":100},"Voir toutes les solutions",{"href":101,"dataGaName":95,"dataGaLocation":46},"/fr-fr/solutions/",[103,128,151],{"title":104,"description":105,"link":106,"items":111},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":107},{"icon":108,"href":109,"dataGaName":110,"dataGaLocation":46},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[112,116,119,124],{"text":113,"config":114},"CI/CD",{"href":115,"dataGaLocation":46,"dataGaName":113},"/fr-fr/solutions/continuous-integration/",{"text":77,"config":117},{"href":82,"dataGaLocation":46,"dataGaName":118},"gitlab duo agent platform - product menu",{"text":120,"config":121},"Gestion du code source",{"href":122,"dataGaLocation":46,"dataGaName":123},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":125,"config":126},"Livraison de logiciels automatisée",{"href":109,"dataGaLocation":46,"dataGaName":127},"Automated software delivery",{"title":129,"description":130,"link":131,"items":136},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":132},{"href":133,"dataGaName":134,"dataGaLocation":46,"icon":135},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[137,141,146],{"text":138,"config":139},"Tests de sécurité des applications",{"href":133,"dataGaName":140,"dataGaLocation":46},"Application security testing",{"text":142,"config":143},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":144,"dataGaLocation":46,"dataGaName":145},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":147,"config":148},"Conformité logicielle",{"href":149,"dataGaName":150,"dataGaLocation":46},"/fr-fr/solutions/software-compliance/","software compliance",{"title":152,"link":153,"items":158},"Mesures",{"config":154},{"icon":155,"href":156,"dataGaName":157,"dataGaLocation":46},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[159,163,168],{"text":160,"config":161},"Visibilité et mesures",{"href":156,"dataGaLocation":46,"dataGaName":162},"Visibility and Measurement",{"text":164,"config":165},"Gestion de la chaîne de valeur",{"href":166,"dataGaLocation":46,"dataGaName":167},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":169,"config":170},"Données d'analyse et informations clés",{"href":171,"dataGaLocation":46,"dataGaName":172},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":174,"type":97,"items":175},"GitLab",[176,182,188],{"text":177,"config":178},"Pour les entreprises",{"icon":179,"href":180,"dataGaLocation":46,"dataGaName":181},"Building","/fr-fr/enterprise/","enterprise",{"text":183,"config":184},"Pour les PME",{"icon":185,"href":186,"dataGaLocation":46,"dataGaName":187},"Work","/fr-fr/small-business/","small business",{"text":189,"config":190},"Pour le secteur public",{"icon":191,"href":192,"dataGaLocation":46,"dataGaName":193},"Organization","/fr-fr/solutions/public-sector/","public sector",{"text":195,"config":196},"Tarifs",{"href":197,"dataGaName":198,"dataGaLocation":46,"dataNavLevelOne":198},"/fr-fr/pricing/","pricing",{"text":200,"config":201,"menu":203},"Ressources",{"dataNavLevelOne":202},"resources",{"type":97,"link":204,"columns":208,"feature":288},{"text":205,"config":206},"Afficher toutes les ressources",{"href":207,"dataGaName":202,"dataGaLocation":46},"/fr-fr/resources/",[209,242,260],{"title":210,"items":211},"Premiers pas",[212,217,222,227,232,237],{"text":213,"config":214},"Installation",{"href":215,"dataGaName":216,"dataGaLocation":46},"/fr-fr/install/","install",{"text":218,"config":219},"Guides de démarrage",{"href":220,"dataGaName":221,"dataGaLocation":46},"/fr-fr/get-started/","quick setup checklists",{"text":223,"config":224},"Apprentissage",{"href":225,"dataGaLocation":46,"dataGaName":226},"https://university.gitlab.com/","learn",{"text":228,"config":229},"Documentation",{"href":230,"dataGaName":231,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":233,"config":234},"Vidéos sur les bonnes pratiques",{"href":235,"dataGaName":236,"dataGaLocation":46},"/fr-fr/getting-started-videos/","best practice videos",{"text":238,"config":239},"Intégrations",{"href":240,"dataGaName":241,"dataGaLocation":46},"/fr-fr/integrations/","integrations",{"title":243,"items":244},"Découvrir",[245,250,255],{"text":246,"config":247},"Témoignages clients",{"href":248,"dataGaName":249,"dataGaLocation":46},"/fr-fr/customers/","customer success stories",{"text":251,"config":252},"Blog",{"href":253,"dataGaName":254,"dataGaLocation":46},"/fr-fr/blog/","blog",{"text":256,"config":257},"Travail à distance",{"href":258,"dataGaName":259,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":261,"items":262},"Connecter",[263,268,273,278,283],{"text":264,"config":265},"Services GitLab",{"href":266,"dataGaName":267,"dataGaLocation":46},"/fr-fr/services/","services",{"text":269,"config":270},"Communauté",{"href":271,"dataGaName":272,"dataGaLocation":46},"/community/","community",{"text":274,"config":275},"Forum",{"href":276,"dataGaName":277,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"Événements",{"href":281,"dataGaName":282,"dataGaLocation":46},"/events/","events",{"text":284,"config":285},"Partenaires",{"href":286,"dataGaName":287,"dataGaLocation":46},"/fr-fr/partners/","partners",{"config":289,"text":292,"image":293,"link":297},{"background":290,"textColor":291},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":294,"config":295},"carte promo The Source",{"src":296},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":298,"config":299},"Lire les articles les plus récents",{"href":300,"dataGaName":301,"dataGaLocation":46},"/fr-fr/the-source/","the source",{"text":303,"config":304,"menu":306},"Société",{"dataNavLevelOne":305},"company",{"type":97,"columns":307},[308],{"items":309},[310,315,321,323,328,333,338,343,348,353,358],{"text":311,"config":312},"À propos",{"href":313,"dataGaName":314,"dataGaLocation":46},"/fr-fr/company/","about",{"text":316,"config":317,"footerGa":320},"Carrières",{"href":318,"dataGaName":319,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":319},{"text":279,"config":322},{"href":281,"dataGaName":282,"dataGaLocation":46},{"text":324,"config":325},"Leadership",{"href":326,"dataGaName":327,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":329,"config":330},"Équipe",{"href":331,"dataGaName":332,"dataGaLocation":46},"/company/team/","team",{"text":334,"config":335},"Manuel",{"href":336,"dataGaName":337,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":339,"config":340},"Relations avec les investisseurs",{"href":341,"dataGaName":342,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":344,"config":345},"Trust Center",{"href":346,"dataGaName":347,"dataGaLocation":46},"/fr-fr/security/","trust center",{"text":349,"config":350},"Centre pour la transparence de l'IA",{"href":351,"dataGaName":352,"dataGaLocation":46},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":354,"config":355},"Newsletter",{"href":356,"dataGaName":357,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":359,"config":360},"Presse",{"href":361,"dataGaName":362,"dataGaLocation":46},"/press/","press",{"text":364,"config":365,"menu":366},"Nous contacter",{"dataNavLevelOne":305},{"type":97,"columns":367},[368],{"items":369},[370,373,378],{"text":53,"config":371},{"href":55,"dataGaName":372,"dataGaLocation":46},"talk to sales",{"text":374,"config":375},"Assistance GitLab",{"href":376,"dataGaName":377,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":379,"config":380},"Portail clients GitLab",{"href":381,"dataGaName":382,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":384,"login":385,"suggestions":392},"Fermer",{"text":386,"link":387},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":388,"config":389},"GitLab.com",{"href":60,"dataGaName":390,"dataGaLocation":391},"search login","search",{"text":393,"default":394},"Suggestions",[395,397,402,404,409,414],{"text":77,"config":396},{"href":82,"dataGaName":77,"dataGaLocation":391},{"text":398,"config":399},"Suggestions de code (IA)",{"href":400,"dataGaName":401,"dataGaLocation":391},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":113,"config":403},{"href":115,"dataGaName":113,"dataGaLocation":391},{"text":405,"config":406},"GitLab sur AWS",{"href":407,"dataGaName":408,"dataGaLocation":391},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":410,"config":411},"GitLab sur Google Cloud",{"href":412,"dataGaName":413,"dataGaLocation":391},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":415,"config":416},"Pourquoi utiliser GitLab ?",{"href":90,"dataGaName":417,"dataGaLocation":391},"Why GitLab?",{"freeTrial":419,"mobileIcon":424,"desktopIcon":429,"secondaryButton":432},{"text":420,"config":421},"Commencer votre essai gratuit",{"href":422,"dataGaName":51,"dataGaLocation":423},"https://gitlab.com/-/trials/new/","nav",{"altText":425,"config":426},"Icône GitLab",{"src":427,"dataGaName":428,"dataGaLocation":423},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":425,"config":430},{"src":431,"dataGaName":428,"dataGaLocation":423},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":433,"config":434},"Commencer",{"href":435,"dataGaName":436,"dataGaLocation":423},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":438,"mobileIcon":442,"desktopIcon":444},{"text":439,"config":440},"En savoir plus sur GitLab Duo",{"href":82,"dataGaName":441,"dataGaLocation":423},"gitlab duo",{"altText":425,"config":443},{"src":427,"dataGaName":428,"dataGaLocation":423},{"altText":425,"config":445},{"src":431,"dataGaName":428,"dataGaLocation":423},{"button":447,"mobileIcon":452,"desktopIcon":454},{"text":448,"config":449},"/switch",{"href":450,"dataGaName":451,"dataGaLocation":423},"#contact","switch",{"altText":425,"config":453},{"src":427,"dataGaName":428,"dataGaLocation":423},{"altText":425,"config":455},{"src":456,"dataGaName":428,"dataGaLocation":423},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":458,"mobileIcon":463,"desktopIcon":465},{"text":459,"config":460},"Retour aux tarifs",{"href":197,"dataGaName":461,"dataGaLocation":423,"icon":462},"back to pricing","GoBack",{"altText":425,"config":464},{"src":427,"dataGaName":428,"dataGaLocation":423},{"altText":425,"config":466},{"src":431,"dataGaName":428,"dataGaLocation":423},{"title":468,"button":469,"config":474},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":470,"config":471},"S'inscrire à GitLab Transcend le 10 juin",{"href":472,"dataGaName":473,"dataGaLocation":46},"/fr-fr/releases/whats-new/#sign-up","transcend event",{"layout":475,"icon":476,"disabled":33},"release","AiStar",{"data":478},{"text":479,"source":480,"edit":486,"contribute":491,"config":496,"items":501,"minimal":706},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":481,"config":482},"Afficher le code source de la page",{"href":483,"dataGaName":484,"dataGaLocation":485},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":487,"config":488},"Modifier cette page",{"href":489,"dataGaName":490,"dataGaLocation":485},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":492,"config":493},"Veuillez contribuer",{"href":494,"dataGaName":495,"dataGaLocation":485},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":497,"facebook":498,"youtube":499,"linkedin":500},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[502,547,600,644,671],{"title":195,"links":503,"subMenu":518},[504,508,513],{"text":505,"config":506},"Voir les forfaits",{"href":197,"dataGaName":507,"dataGaLocation":485},"view plans",{"text":509,"config":510},"GitLab Premium",{"href":511,"dataGaName":512,"dataGaLocation":485},"/fr-fr/pricing/premium/","why premium",{"text":514,"config":515},"GitLab Ultimate",{"href":516,"dataGaName":517,"dataGaLocation":485},"/fr-fr/pricing/ultimate/","why ultimate",[519],{"title":364,"links":520},[521,523,525,527,532,537,542],{"text":53,"config":522},{"href":55,"dataGaName":56,"dataGaLocation":485},{"text":374,"config":524},{"href":376,"dataGaName":377,"dataGaLocation":485},{"text":379,"config":526},{"href":381,"dataGaName":382,"dataGaLocation":485},{"text":528,"config":529},"Statut",{"href":530,"dataGaName":531,"dataGaLocation":485},"https://status.gitlab.com/","status",{"text":533,"config":534},"Conditions d'utilisation",{"href":535,"dataGaName":536,"dataGaLocation":485},"/terms/","terms of use",{"text":538,"config":539},"Politique de confidentialité",{"href":540,"dataGaName":541,"dataGaLocation":485},"/fr-fr/privacy/","privacy statement",{"text":543,"config":544},"Gérer vos cookies",{"dataGaName":545,"dataGaLocation":485,"id":546,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"title":93,"links":548,"subMenu":557},[549,553],{"text":550,"config":551},"Plateforme DevSecOps",{"href":75,"dataGaName":552,"dataGaLocation":485},"devsecops platform",{"text":554,"config":555},"Développement assisté par l'IA",{"href":82,"dataGaName":556,"dataGaLocation":485},"ai-assisted development",[558],{"title":559,"links":560},"Thèmes",[561,565,570,575,580,585,590,595],{"text":113,"config":562},{"href":563,"dataGaName":564,"dataGaLocation":485},"/fr-fr/topics/ci-cd/","cicd",{"text":566,"config":567},"GitOps",{"href":568,"dataGaName":569,"dataGaLocation":485},"/fr-fr/topics/gitops/","gitops",{"text":571,"config":572},"DevOps",{"href":573,"dataGaName":574,"dataGaLocation":485},"/fr-fr/topics/devops/","devops",{"text":576,"config":577},"Contrôle de version",{"href":578,"dataGaName":579,"dataGaLocation":485},"/fr-fr/topics/version-control/","version control",{"text":581,"config":582},"DevSecOps",{"href":583,"dataGaName":584,"dataGaLocation":485},"/fr-fr/topics/devsecops/","devsecops",{"text":586,"config":587},"Cloud-native",{"href":588,"dataGaName":589,"dataGaLocation":485},"/fr-fr/topics/cloud-native/","cloud native",{"text":591,"config":592},"IA pour la programmation",{"href":593,"dataGaName":594,"dataGaLocation":485},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":596,"config":597},"IA agentique",{"href":598,"dataGaName":599,"dataGaLocation":485},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":601,"links":602},"Solutions",[603,606,608,613,616,619,622,625,628,631,634,639],{"text":138,"config":604},{"href":133,"dataGaName":605,"dataGaLocation":485},"Application Security Testing",{"text":125,"config":607},{"href":109,"dataGaName":110,"dataGaLocation":485},{"text":609,"config":610},"Développement Agile",{"href":611,"dataGaName":612,"dataGaLocation":485},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":120,"config":614},{"href":122,"dataGaName":615,"dataGaLocation":485},"source code management",{"text":113,"config":617},{"href":115,"dataGaName":618,"dataGaLocation":485},"continuous integration & delivery",{"text":164,"config":620},{"href":166,"dataGaName":621,"dataGaLocation":485},"value stream management",{"text":566,"config":623},{"href":624,"dataGaName":569,"dataGaLocation":485},"/fr-fr/solutions/gitops/",{"text":626,"config":627},"Entreprises",{"href":180,"dataGaName":181,"dataGaLocation":485},{"text":629,"config":630},"PME",{"href":186,"dataGaName":187,"dataGaLocation":485},{"text":632,"config":633},"Secteur public",{"href":192,"dataGaName":193,"dataGaLocation":485},{"text":635,"config":636},"Éducation",{"href":637,"dataGaName":638,"dataGaLocation":485},"/fr-fr/solutions/education/","education",{"text":640,"config":641},"Services financiers",{"href":642,"dataGaName":643,"dataGaLocation":485},"/fr-fr/solutions/finance/","financial services",{"title":200,"links":645},[646,648,650,652,655,657,659,661,663,665,667,669],{"text":213,"config":647},{"href":215,"dataGaName":216,"dataGaLocation":485},{"text":218,"config":649},{"href":220,"dataGaName":221,"dataGaLocation":485},{"text":223,"config":651},{"href":225,"dataGaName":226,"dataGaLocation":485},{"text":228,"config":653},{"href":230,"dataGaName":654,"dataGaLocation":485},"docs",{"text":251,"config":656},{"href":253,"dataGaName":254,"dataGaLocation":485},{"text":246,"config":658},{"href":248,"dataGaName":249,"dataGaLocation":485},{"text":256,"config":660},{"href":258,"dataGaName":259,"dataGaLocation":485},{"text":264,"config":662},{"href":266,"dataGaName":267,"dataGaLocation":485},{"text":269,"config":664},{"href":271,"dataGaName":272,"dataGaLocation":485},{"text":274,"config":666},{"href":276,"dataGaName":277,"dataGaLocation":485},{"text":279,"config":668},{"href":281,"dataGaName":282,"dataGaLocation":485},{"text":284,"config":670},{"href":286,"dataGaName":287,"dataGaLocation":485},{"title":303,"links":672},[673,675,677,679,681,683,685,690,695,697,699,701],{"text":311,"config":674},{"href":313,"dataGaName":305,"dataGaLocation":485},{"text":316,"config":676},{"href":318,"dataGaName":319,"dataGaLocation":485},{"text":324,"config":678},{"href":326,"dataGaName":327,"dataGaLocation":485},{"text":329,"config":680},{"href":331,"dataGaName":332,"dataGaLocation":485},{"text":334,"config":682},{"href":336,"dataGaName":337,"dataGaLocation":485},{"text":339,"config":684},{"href":341,"dataGaName":342,"dataGaLocation":485},{"text":686,"config":687},"Développement durable",{"href":688,"dataGaName":689,"dataGaLocation":485},"/sustainability/","Sustainability",{"text":691,"config":692},"Diversité, inclusion et appartenance (DIB)",{"href":693,"dataGaName":694,"dataGaLocation":485},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":344,"config":696},{"href":346,"dataGaName":347,"dataGaLocation":485},{"text":354,"config":698},{"href":356,"dataGaName":357,"dataGaLocation":485},{"text":359,"config":700},{"href":361,"dataGaName":362,"dataGaLocation":485},{"text":702,"config":703},"Déclaration de transparence sur l'esclavage moderne",{"href":704,"dataGaName":705,"dataGaLocation":485},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":707},[708,710,713],{"text":533,"config":709},{"href":535,"dataGaName":536,"dataGaLocation":485},{"text":711,"config":712},"Gestion des cookies",{"dataGaName":545,"dataGaLocation":485,"id":546,"isOneTrustButton":15},{"text":538,"config":714},{"href":540,"dataGaName":541,"dataGaLocation":485},[716],{"id":717,"title":9,"body":28,"config":718,"content":720,"description":28,"extension":724,"meta":725,"navigation":15,"path":726,"seo":727,"stem":728,"__hash__":729},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":719},"BlogAuthor",{"name":9,"config":721},{"headshot":722,"ctfId":723},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab","yml",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[731,742,755],{"content":732,"config":740},{"title":733,"description":734,"body":735,"category":11,"tags":736,"date":737,"heroImage":738,"authors":739},"Nouveautés de Git 2.54.0","Découvrez les contributions à cette release de Git 2.54.0, notamment la nouvelle maintenance des dépôts, une nouvelle commande pour modifier l'historique des commits, le remplacement de git-sizer(1) et plus encore.","Le projet Git a récemment publié [Git 2.54.0](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u). Passons en revue quelques-unes des nouveautés marquantes de cette release, qui comprend des contributions de l'équipe Git chez GitLab.\n\n\n## Bases de données d'objets modulaires\n\n\n[Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") offre déjà la possibilité de stocker les références avec le backend « files » ou avec le [backend « reftable »](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/). Ce scénario est rendu possible grâce à des abstractions appropriées dans Git qui permettent de disposer de différents backends.\n\n\nMais les références ne constituent qu'un des deux types importants de données stockées dans les dépôts, l'autre étant les objets. Les objets sont stockés dans la base de données d'objets, et chaque base de données d'objets est à son tour composée de plusieurs sources d'objets à partir desquelles les objets peuvent être lus ou écrits. Chaque source d'objets stocke soit des objets individuels sous forme d'objets dits « libres », soit compresse plusieurs objets dans un fichier d'empaquetage (« packfile ») dans le répertoire `.git/objects`.\n\n\nJusqu'à présent, cependant, ces sources ne disposaient pas d'une couche d'abstraction appropriée, de sorte que le format de stockage des objets était entièrement codé en dur dans Git. Mais les choses changent enfin avec les bases de données d'objets enfichables. Le concept est simple et similaire à ce qui a été fait pour les références par le passé : au lieu de chemins de code en dur pour le stockage des objets, nous introduisons une couche d'abstraction qui permet de disposer de différents backends pour le stockage des objets.\n\n\nSi l'idée est simple, la mise en œuvre ne l'est pas, car les spécificités des formats de stockage sont codées en dur partout dans Git. En réalité, nous avons commencé à travailler sur ce projet dès Git 2.48, qui a été publié en janvier 2025. Dans un premier temps, nous nous sommes concentrés sur l'encapsulation des sous-systèmes liés aux objets et sur la création de sous-systèmes dédiés pour les backends existants dans Git.\n\n\nAvec Git 2.54, nous franchissons une étape importante : le backend de la base de données d'objets est désormais modulaire. Toutes les fonctionnalités de Git ne sont pas encore couvertes, mais l'introduction d'un backend alternatif capable de gérer un sous-ensemble significatif d'opérations est désormais un objectif réaliste.\n\n\nPour l'instant, seuls les workflows locaux comme la création de commits, l'affichage de graphes de commits ou l'exécution de merges fonctionneront avec une telle implémentation alternative. Cette approche exclut notamment tout ce qui interagit avec un dépôt distant, comme les opérations de récupération ou de push de modifications. Quoi qu'il en soit, il s'agit de l'aboutissement de près de deux ans de travail, répartis sur près de 400 commits fusionnés en amont, et nous continuerons bien entendu à itérer.\n\n\nMais pourquoi ce projet est-il important ? L'objectif est de simplifier l'introduction de nouveaux formats de stockage dans Git. Voici quelques exemples :\n\n- Un format de stockage capable de gérer les fichiers binaires volumineux de manière plus efficace que les fichiers d'empaquetage actuels\n\n- Un format de stockage sur mesure pour GitLab afin de garantir que nous puissions servir les dépôts à nos utilisateurs de manière encore plus efficace qu'actuellement\n\n\nIl s'agit d'un effort à grande échelle qui est susceptible de façonner l'avenir de Git et de GitLab.\n\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n## Modification simplifiée de votre historique de commits\n\n\nDans de nombreux projets de développement logiciel, il est courant pour les développeurs de ne pas seulement peaufiner le code qu'ils souhaitent soumettre, mais aussi de soigner l'historique des commits afin de faciliter la revue. Le résultat est un ensemble de commits petits et atomiques, chacun dédié à une seule tâche, accompagné d'un bon message de commit qui décrit l'intention ainsi que les nuances spécifiques.\n\n\nBien entendu, ces commits atomiques ne sont le plus souvent pas le fruit naturel du processus de développement. L'auteur des modifications acquiert plutôt une meilleure compréhension au fur et à mesure des itérations, et la manière de découper les commits se clarifie avec le temps. De plus, le processus de revue qui s'ensuit peut donner lieu à des retours nécessitant des modifications des commits déjà préparés.\n\n\nPar conséquent, le développeur devra réécrire son historique de commits de nombreuses fois au cours du développement. Git offre depuis longtemps cette possibilité via les [rebasages interactifs](https://git-scm.com/docs/git-rebase#_interactive_mode). Ces rebasages interactifs sont un outil extrêmement puissant : ils permettent de réordonner les commits, de réécrire les messages de commits, de regrouper plusieurs commits ou d'effectuer des modifications arbitraires sur n'importe quel commit.\n\n\nMais ils sont aussi quelque peu obscurs et difficiles à appréhender. L'utilisateur doit identifier le commit de base pour le rebasage, comprendre comment modifier une « feuille d'instructions » assez obscure et connaître le fonctionnement à état du processus de rebasage. Par exemple, les utilisateurs se voient présenter une feuille d'instructions similaire à celle ci-dessous lors du rebasage d'une branche thématique :\n\n```shell\npick b60623f382 # t: detect errors outside of test cases # empty\npick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`\npick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`\npick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`\npick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`\npick ed0e7ca2b5 # t: detect errors outside of test cases\n```\n\nAinsi, bien que les rebasages interactifs soient puissants, ils restent assez intimidants pour l'utilisateur moyen.\n\n\nMais ce n'est pas une fatalité. Des outils comme [Jujutsu](https://www.jj-vcs.dev/latest/) offrent des interfaces beaucoup plus simples d'utilisation par rapport à Git, puisqu'il suffit par exemple d'exécuter `jj split` pour diviser un commit en deux. Avec Git et les rebasages interactifs, ce cas d'utilisation requiert de nombreuses étapes avec des arguments en ligne de commande peu explicites.\n\n\nNous nous sommes donc inspirés de Jujutsu et avons introduit dans Git une nouvelle commande git-history(1), qui constitue le socle d'une meilleure modification de l'historique. Pour l'instant, cette commande dispose de deux sous-commandes :\n\n\n- `git history reword` vous permet de réécrire facilement un message de commit. Il vous suffit d'indiquer le commit que vous souhaitez mieux documenter, Git vous demande le nouveau message de commit, et c'est terminé.\n\n- `git history split` vous permet de diviser un commit en deux, à l'image de `jj split`. Vous indiquez un commit, Git vous demande quelles modifications mettre dans quel commit ainsi que les deux messages de commit, et c'est terminé.\n\n\nCe n'est bien sûr qu'un début, et nous souhaitons ajouter des sous-commandes supplémentaires au fil du temps. Par exemple :\n\n\n- `git history fixup` pour prendre les modifications indexées et les intégrer automatiquement à un commit spécifique\n\n- `git history drop` pour supprimer un commit\n\n- `git history reorder` pour réordonner la séquence de commits\n\n- `git history squash` pour regrouper une série de commits\n\n\nMais ce n'est pas tout. En plus de simplifier la modification de l'historique, cette nouvelle commande sait aussi rebaser automatiquement toutes vos branches locales qui incluaient précédemment ce commit. Cela signifie que vous pouvez modifier un commit qui ne se trouve pas sur la branche courante, et toutes les branches contenant ce commit seront réécrites.\n\n\nAu premier abord, il peut sembler surprenant que Git rebase automatiquement les branches dépendantes, car cela constitue une divergence significative par rapport au fonctionnement de git-rebase(1). Mais cela s'inscrit dans un effort plus large visant à améliorer la prise en charge des « diffs empilés » (« Stacked Diffs ») dans Git, une méthode permettant de créer une série de plusieurs branches dépendantes pouvant être revues indépendamment, mais qui concourent ensemble à un objectif plus vaste.\n\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab) avec le soutien d'[Elijah Newren](https://github.com/newren).*\n\n\n## Remplacement natif de git-sizer(1)\n\n\nLa taille d'un dépôt Git est un facteur important qui détermine la capacité de Git et de GitLab à le gérer efficacement. Mais la taille n'est pas le seul facteur, car les performances d'un dépôt résultent en définitive d'une combinaison de plusieurs aspects :\n\n\n- La taille de l'historique des commits\n\n- La structure de l'arborescence des répertoires\n\n- La taille des fichiers stockés dans le dépôt\n\n- Le nombre de références\n\n\nCe ne sont là que quelques-uns des aspects à prendre en compte pour prédire si Git sera en mesure de gérer correctement un dépôt.\n\n\nBien qu'il soit clair que la simple taille du dépôt est insuffisante, Git ne fournit en soi aucun outil offrant à l'utilisateur une vue d'ensemble claire de ces indicateurs. Les utilisateurs sont contraints de s'appuyer sur des outils tiers comme [git-sizer(1)](https://github.com/github/git-sizer) pour combler cette lacune. Cet outil fait un excellent travail pour afficher ces informations, mais il ne fait pas partie de Git et doit donc être installé séparément.\n\n\nL'observabilité des composants internes d'un dépôt est essentielle chez GitLab. C'est pourquoi nous avons introduit [une nouvelle sous-commande `git repo structure` dans Git 2.52](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-52-0/#new-subcommand-for-git-repo1-to-display-repository-metrics) pour afficher les indicateurs du dépôt, que nous avons étendue dans Git 2.53 pour [afficher les tailles décompressées et sur disque des objets par type](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-53-0/#more-data-collected-in-git-repo-structure).\n\n\nDans Git 2.54, nous itérons davantage sur cette commande afin de ne pas seulement afficher la taille globale, mais aussi les objets les plus volumineux par type :\n\n```shell\n$ git clone https://gitlab.com/git-scm/git.git\n$ cd git\n$ git repo structure\nCounting objects: 410445, done.\n| Repository structure      | Value       |\n| ------------------------- | ----------- |\n| * References              |             |\n|   * Count                 |    1.01 k   |\n|     * Branches            |       1     |\n|     * Tags                |    1.00 k   |\n|     * Remotes             |       9     |\n|     * Others              |       0     |\n|                           |             |\n| * Reachable objects       |             |\n|   * Count                 |  410.45 k   |\n|     * Commits             |   83.99 k   |\n|     * Trees               |  164.46 k   |\n|     * Blobs               |  161.00 k   |\n|     * Tags                |    1.00 k   |\n|   * Inflated size         |    7.46 GiB |\n|     * Commits             |   57.53 MiB |\n|     * Trees               |    2.33 GiB |\n|     * Blobs               |    5.07 GiB |\n|     * Tags                |  737.48 KiB |\n|   * Disk size             |  181.37 MiB |\n|     * Commits             |   33.11 MiB |\n|     * Trees               |   40.58 MiB |\n|     * Blobs               |  107.11 MiB |\n|     * Tags                |  582.67 KiB |\n|                           |             |\n| * Largest objects         |             |\n|   * Commits               |             |\n|     * Maximum size    [1] |   17.23 KiB |\n|     * Maximum parents [2] |      10     |\n|   * Trees                 |             |\n|     * Maximum size    [3] |   58.85 KiB |\n|     * Maximum entries [4] |    1.18 k   |\n|   * Blobs                 |             |\n|     * Maximum size    [5] | 1019.51 KiB |\n|   * Tags                  |             |\n\n|     * Maximum size    [6] |    7.13 KiB |\n\n[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf\n[2] 16d7601e176cd53f3c2f02367698d06b85e08879\n[3] 203ee97047731b9fd3ad220faa607b6677861a0d\n[4] 203ee97047731b9fd3ad220faa607b6677861a0d\n[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543\n[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc\n```\n\nAvec ces informations, nous sommes désormais presque au niveau de parité fonctionnelle avec git-sizer(1). Nous n'avons cependant pas encore terminé : nous prévoyons à terme d'ajouter des fonctionnalités supplémentaires telles que :\n\n\n- Des niveaux de gravité tels qu'ils existent dans git-sizer(1)\n\n- Des graphes affichant la distribution des tailles d'objets\n\n- La possibilité de scanner les objets accessibles via un sous-ensemble de références\n\n\n*Ce projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).*\n\n\n## Nouvelle infrastructure pour la maintenance des dépôts\n\n\nChaque fois que vous écrivez des données dans un dépôt Git, vous ajoutez généralement de nouveaux objets libres. Sans intervention, vous obtiendrez un grand nombre de fichiers distincts dans votre répertoire `.git/objects/`, ce qui ralentit plusieurs opérations nécessitant l'accès à de nombreux objets simultanément. Git compresse donc régulièrement ces objets dans des fichiers d'empaquetage pour garantir de bonnes performances.\n\n\nCe n'est pas la seule structure de données susceptible de perdre en efficacité au fil du temps : la mise à jour des références peut créer des références libres, les reflogs doivent être allégés, les arbres de travail peuvent devenir obsolètes et les caches comme les graphes de commits doivent être actualisés régulièrement.\n\n\nHistoriquement, toutes ces tâches étaient gérées par [git-gc(1)](https://git-scm.com/docs/git-gc). Cependant, cet outil possède une architecture monolithique, exécutant essentiellement toutes les tâches requises dans un ordre séquentiel. Cette base est difficile à étendre et n'offre pas à l'utilisateur beaucoup de flexibilité s'il souhaite modifier légèrement la façon dont la maintenance est effectuée.\n\n\nLe projet Git a introduit le nouvel outil [git-maintenance(1)](https://git-scm.com/docs/git-maintenance) dans Git 2.29. Contrairement à git-gc(1), git-maintenance(1) n'est pas monolithique mais est structuré autour de tâches. Ces tâches sont librement configurables par l'utilisateur, ce qui lui offre un contrôle beaucoup plus précis sur la maintenance du dépôt.\n\n\nAu bout du compte, Git a migré vers git-maintenance(1) par défaut. Mais au départ, la seule tâche activée par défaut était la tâche git-gc(1) qui, comme vous l'aurez deviné, exécute simplement `git gc`. Pour lancer manuellement la maintenance avec cette nouvelle commande, il suffit d'exécuter `git maintenance run`, mais Git sait l'exécuter automatiquement à la suite de plusieurs autres commandes.\n\n\nAu cours des dernières releases, nous avons implémenté toutes les tâches individuelles prises en charge par git-gc(1) dans git-maintenance(1) afin de garantir la parité fonctionnelle entre ces deux outils.\n\n\nDe plus, nous avons implémenté une nouvelle tâche qui utilise l'architecture moderne de Git pour le rempaquetage d'objets avec le [compactage géométrique](https://git-scm.com/docs/git-repack#Documentation/git-repack.txt---geometricfactor). Le compactage géométrique est bien mieux adapté aux grands monorepos, et grâce à nos efforts, [intégrés dans Git 2.53](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-53-0/#geometric-repacking-support-with-promisor-remotes), pour le faire fonctionner avec les clones partiels, il constitue désormais un remplacement complet de notre précédente stratégie de rempaquetage dans Git.\n\n\nAvec Git 2.54, nous avons franchi une autre étape importante : au lieu d'utiliser la stratégie basée sur git-gc(1) par défaut, nous utilisons désormais le rempaquetage géométrique avec des tâches de maintenance individuelles et granulaires. Outre son efficacité accrue pour les grands monorepos, il offre également une base plus facile à partir de laquelle itérer.\n\n\n*L'infrastructure de git-maintenance(1) a été initialement implémentée par [Derrick Stolee](https://github.com/derrickstolee), et la maintenance géométrique a été introduite par [Taylor Blau](https://github.com/ttaylorr). L'effort d'introduction des nouvelles tâches granulaires et de migration vers la nouvelle stratégie de maintenance a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n## Pour en savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière release. Vous pouvez en apprendre davantage dans l'[annonce de release officielle](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [articles de blog précédents sur les releases de Git](https://about.gitlab.com/fr-fr/blog/tags/git/) pour découvrir d'autres contributions des membres de l'équipe GitLab.",[23,21,272],"2026-04-27","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1776711651/sj7xxyyuimlarswbyft5.png",[9],{"featured":33,"template":13,"slug":741},"whats-new-in-git-2-54-0",{"content":743,"config":753},{"title":744,"description":745,"authors":746,"heroImage":748,"date":749,"body":750,"category":11,"tags":751},"GitLab AI Hackathon 2026 : découvrez les gagnants","Près de 7 000 développeurs ont créé plus de 600 agents et flows d'IA sur GitLab Duo Agent Platform. Découvrez les gagnants et leurs projets.",[747],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","2026-04-22","Il est désormais acquis que l'IA écrit du code. Mais qu'en est-il de la planification, de la sécurité, de la conformité et des déploiements ? Dans ces domaines, des lacunes persistent. Nous organisons des programmes de contribution depuis des années et n'avons jamais vu une communauté réagir à une technologie de cette manière.\n\nC'est pourquoi nous avons lancé [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) et invité des équipes de développement du monde entier à créer des agents d'IA qui aident les équipes à livrer des logiciels sécurisés plus rapidement. Pas des chatbots qui répondent à des questions, mais des agents qui s'intègrent dans les workflows, réagissent aux événements et agissent en votre nom. Le GitLab AI Hackathon 2026 s'est déroulé du 9 février au 25 mars 2026 sur Devpost, la plateforme dédiée aux hackathons. Google Cloud et Anthropic y ont participé en tant que co-sponsors.\n\nLorsque nous avons préparé ce hackathon avec Google Cloud et Anthropic, nous avons demandé aux juges d'évaluer quatre critères : la qualité technique, le design, l'impact potentiel et l'originalité de l'idée. Nous espérions une forte participation, mais les résultats nous ont tous surpris. Dix-neuf juges ont consacré 18 jours à examiner tous les projets. Google Cloud et Anthropic ont fourni les juges, les prix et un accès cloud. La communauté a créé des centaines d'agents et de flows afin de s'atteler aux lacunes mentionnées plus haut.\n\nPrès de 7 000 développeurs ont répondu à l'appel et créé plus de 600 agents et flows en quelques semaines. Les prix, toutes catégories confondues, totalisaient 65 000 dollars offerts par GitLab, Google Cloud et Anthropic.\n\n\nSi vous avez déjà vu un ingénieur senior quitter une équipe en emportant avec lui la moitié des connaissances de son équipe, vous comprendrez pourquoi le projet gagnant a autant marqué les esprits.\n\nPoursuivez votre lecture pour découvrir ce que les participants ont créé.\n\n## Premier prix : LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine), le Living Organizational Record Engine, utilise huit agents avec un routeur qui dirige chaque question vers l'agent approprié, une logique de prévention des boucles circulaires dans le graphe de connaissances, un tableau de bord visuel et un suivi de l'empreinte carbone. L'outil en ligne de commande est livré avec 43 tests (un chiffre inédit dans un projet de hackathon).\n\nLORE résout un problème concret : les connaissances des ingénieurs qui disparaissent lorsque ces derniers quittent l'entreprise. D'après notre expérience, un projet de hackathon avec 43 tests est rare. Un tel nombre en dit long sur l'équipe qui l'a conçu.\n\nApril Guo (Anthropic), membre du jury, a écrit : « On dirait un produit, pas un projet de hackathon. »\n\n\n### Gagnants Google Cloud\n\n[Gitdefender](https://devpost.com/software/gitdefender) a remporté le premier prix Google Cloud. L'outil s'intègre dans les workflows de revue de code afin de détecter et de corriger les vulnérabilités de sécurité. Il identifie les bogues, rédige des correctifs et ouvre la revue de code. Aucune intervention humaine n'est nécessaire.\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0) a remporté le deuxième prix Google Cloud. L'outil fournit des explications assistées par l'IA pour chaque décision prise, qui est déployée sur Google Cloud et prête pour la production.\n\n### Gagnants Anthropic\n\n[GraphDev](https://devpost.com/software/graphdev) a remporté le premier prix Anthropic. L'outil cartographie les liens entre les éléments du code et montre comment les systèmes évoluent au fil du temps. Aboobacker MK (GitLab), membre du jury, a noté que le projet était « en phase avec notre travail sur le graphe de connaissances GitLab ». Ayush Billore (GitLab) a écrit : « J'ai adoré la démo et l'expérience utilisateur, un outil très utile pour comprendre comment le système a évolué et ce qui est impacté par les changements. » Vous pouvez visualiser l'impact complet d'une modification avant de l'autoriser.\n\n[DocSync](https://devpost.com/software/pipeheal) a remporté le deuxième prix Anthropic. L'outil utilise trois agents : Detector, Writer et Reviewer. Si DocSync a confiance dans le correctif, il ouvre une revue de code. Dans le cas contraire, il crée un ticket pour qu'un humain le vérifie.\n\n## Gagnants par catégorie\n\n### Projet le plus impressionnant sur le plan technique\n\nLes migrations de bases de données sont source de problèmes. [Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0) crée une copie sécurisée de votre environnement de production, exécute la migration sur cette copie et génère un rapport. L'outil exécute cinq agents connectés par un pont, avec un déploiement réel sur Google Cloud, de véritables migrations PostgreSQL et des données réelles.\n\n### Projet avec le plus grand impact\n\n[RedAgent](https://devpost.com/software/redagent) vérifie les rapports de sécurité générés par l'IA et comble le fossé de confiance entre les résultats de l'IA et l'action des équipes de développement. Si votre équipe utilise l'IA pour les scans de sécurité, vous connaissez ce problème. Certaines équipes ignorent les résultats de l'IA parce qu'elles ne peuvent pas les vérifier. RedAgent offre aux équipes un moyen de valider les résultats de l'IA avant qu'ils ne parviennent aux équipes de développement.\n\n### Projet le plus facile à utiliser\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az) offre une expérience utilisateur soignée et une infrastructure solide, avec également de bons résultats en matière de durabilité.\n\n## Le signal de durabilité\n\nCinq projets ont remporté des prix ou des bonus pour leur impact environnemental. La livraison logicielle a un coût carbone lié aux pipelines CI/CD, et désormais les grands modèles de langage (LLM) consomment également des ressources de calcul à grande échelle. Nous avons créé la catégorie Green Agent pour inciter les équipes de développement à mesurer et réduire cette empreinte. Stacy Cline et Kim Buncle, de l'équipe durabilité de GitLab, ont participé au jury de la catégorie Green Agent.\n\n### Prix Green Agent\n\n[GreenPipe](https://devpost.com/software/greenpipe) analyse les pipelines CI/CD pour évaluer leur impact environnemental et produit des rapports d'empreinte carbone. Kim Buncle et Rajesh Agadi (Google), membres du jury, ont tous deux soutenu le projet.\n\n### Prix bonus consacrés au design durable\n\nLes prix bonus consacrés au design durable ont été attribués aux projets ayant adopté des pratiques de durabilité exceptionnelles dans leur conception, des techniques d'optimisation des modèles aux choix d'architecture écoénergétique.\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer) a transformé un rapport de bogue en 10 correctifs en 20 minutes.\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system) propose des tests à données aléatoires automatisés pour la sécurité.\n* [CarbonLint](https://devpost.com/software/carbonlint) applique l'analyse de code à la consommation énergétique.\n* [TFGuardian](https://devpost.com/software/tfguardian) intègre un analyseur d'empreinte carbone, entre autres agents.\n\nFélicitations à tous les lauréats des prix bonus consacrés au design durable !\n\nJens-Joris Decorte (TechWolf), membre du jury, a mentionné que les coûts étaient passés de 556 $ à 18 $ par mois, soit une réduction de 96 % de l'empreinte carbone (une économie mensuelle de 538 $ assortie d'un label de durabilité).\n\n## Mentions honorables et projets remarquables\n\nSix projets ont reçu des mentions honorables :\n\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey) injecte des vulnérabilités connues dans une branche de test et évalue la capacité de vos scanners de sécurité à les détecter.\n- [stregent](https://devpost.com/software/stregent) surveille les pipelines CI/CD et permet aux équipes de développement d'analyser et de fusionner des correctifs depuis WhatsApp, sans ouvrir un ordinateur portable.\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance) attribue un score de risque de conformité à chaque merge request et bloque le merge si des violations critiques sont détectées.\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf) calcule l'empreinte carbone de chaque job de pipeline CI/CD et publie des conseils d'optimisation sur la merge request.\n- [RepoWarden](https://devpost.com/software/docuguard) est le premier Living Specification Engine, un système d'IA qui capture les raisons pour lesquelles le code a été écrit, et pas seulement ce qu'il fait.\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor) collecte des preuves à travers les merge requests, les associe aux contrôles SOC 2 et diffuse les scores de conformité sur un tableau de bord en temps réel.\n\nMa citation préférée du jury vient de Luca Chun Lun Lit (Anthropic), à propos de l'approche axée sur mobile de stregent : « Pouvoir coder depuis son téléphone représente un nouveau cap dans l'expérience d'ingénierie. »\n\n> Explorez les plus de 600 projets dans la [galerie de projets](https://gitlab.devpost.com/project-gallery).\n\n## Et ensuite ?\n\nChaque agent de ce hackathon fonctionnait au sein d'un seul projet. Les résultats obtenus étaient néanmoins impressionnants. Certains participants ont exécuté un graphe de connaissances local en parallèle de leurs agents pour faire émerger les relations et les dépendances au sein du dépôt. LORE capture l'historique du projet. Gitdefender détecte les vulnérabilités. Associer des agents à un contexte local plus riche aide déjà les contributeurs à créer des outils plus performants. Le prochain hackathon s'appuiera sur ce que les contributeurs font déjà avec un contexte enrichi. Inscrivez-vous sur [contributors.gitlab.com](https://contributors.gitlab.com/) pour être informé dès que les détails seront disponibles.\n\n\n## Lancez-vous\n\nUn grand merci à Lee Tickett (GitLab) et Mattias Michaux (GitLab) pour avoir guidé les innovateurs de ce hackathon !\n\nMerci à chaque développeur qui a soumis un projet. Près de 7 000 d'entre vous ont démontré ce que GitLab Duo Agent Platform peut accomplir lorsqu'une communauté décide de créer. Nous sommes fiers de ce que vous avez produit ici et avons hâte de voir ce que vous créerez ensuite.\n\nCréez votre propre agent sur [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/). Parcourez les agents créés par la communauté dans le [catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/). Vous orchestrez les agents. L'IA accélère le développement.\n",[752,272],"AI/ML",{"featured":33,"template":13,"slug":754},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":756,"config":765},{"tags":757,"category":11,"body":758,"date":759,"heroImage":760,"authors":761,"description":763,"title":764},[23,21,272],"Le projet Git a récemment publié [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u). Passons en revue quelques points marquants de cette version, qui comprend des contributions de l'équipe Git chez GitLab.\n\n\n## Prise en charge du rempaquetage géométrique avec les dépôts distants promisor\n\n\nLes objets qui viennent d'être créés dans un dépôt Git sont souvent stockés sous forme de fichiers libres individuels. Pour garantir de bonnes performances et une utilisation optimale de l'espace disque, ces objets libres sont régulièrement compressés dans ce qu'on appelle des fichiers d'empaquetage (« packfiles »). Le nombre de fichiers d'empaquetage dans un dépôt augmente au fil du temps en raison des tâches effectuées, comme la création de nouveaux commits ou la récupération depuis un dépôt distant. À mesure que le nombre de fichiers d'empaquetage augmente dans un dépôt, Git doit effectuer davantage de travail pour rechercher des objets individuels. Par conséquent, pour préserver les performances optimales du dépôt, les fichiers d'empaquetage sont périodiquement rempaquetés via git-repack(1) afin de consolider les objets dans un nombre réduit de fichiers d'empaquetage. Lors du rempaquetage, deux stratégies existent : « tout-en-un » et « géométrique ».\n\n\nLa stratégie tout-en-un est assez simple et constitue la stratégie par défaut actuelle. Comme son nom l'indique, tous les objets du dépôt sont empaquetés dans un seul fichier. Cette approche est idéale pour le dépôt d'un point de vue des performances, car Git n'a besoin de parcourir qu'un seul fichier d'empaquetage lors de la recherche d'objets. Le principal inconvénient ? Le calcul d'un fichier d'empaquetage unique pour un dépôt peut prendre beaucoup de temps en cas de dépôt volumineux.\n\n\nLa stratégie géométrique permet d'atténuer ce problème en maintenant une progression géométrique des fichiers d'empaquetage en fonction de leur taille, au lieu de toujours rempaqueter dans un seul fichier. Lors du rempaquetage, Git maintient un ensemble de fichiers d'empaquetage classés par taille, où chaque fichier de la séquence doit avoir au moins deux fois la taille du fichier d'empaquetage précédent. Si un fichier d'empaquetage de la séquence enfreint cette propriété, les fichiers d'empaquetage sont combinés selon les besoins jusqu'à ce que la progression soit rétablie. Cette stratégie permet de limiter le nombre de fichiers d'empaquetage dans un dépôt tout en minimisant également la quantité de travail à effectuer pour la plupart des opérations de rempaquetage.\n\n\nToutefois, la stratégie de rempaquetage géométrique n'était pas compatible avec les clones partiels. Ces derniers permettent de cloner uniquement certaines parties d'un dépôt (par exemple en ignorant tous les blobs de plus de 1 mégaoctet). Cette approche peut réduire considérablement la taille d'un dépôt, et Git sait comment récupérer les objets manquants auxquels il doit accéder ultérieurement.\n\n\nRésultat : nous obtenons un dépôt dans lequel il manque certains objets. Tout objet qui pourrait ne pas être entièrement connecté est stocké dans un fichier d'empaquetage « promisor ». Lors du rempaquetage, cette propriété promisor doit être conservée pour les fichiers d'empaquetage contenant un objet promisor, afin qu'il soit possible de déterminer si un objet manquant est attendu et peut être récupéré depuis le dépôt distant promisor. Avec une stratégie de rempaquetage tout-en-un, Git sait gérer correctement les objets promisor et les stocke dans un fichier d'empaquetage promisor distinct. Malheureusement, la stratégie de rempaquetage géométrique ne savait pas comment accorder un traitement spécial aux fichiers d'empaquetage promisor et les fusionnait avec des fichiers d'empaquetage normaux sans tenir compte de la présence d'objets promisor. Heureusement, en raison d'un bogue, la commande git-pack-objects(1) sous-jacente échoue lors de l'utilisation du rempaquetage géométrique dans un dépôt de clone partiel. Les dépôts dans cette configuration ne pouvaient donc de toute façon pas être rempaquetés. Ce n'est pas idéal, mais c'est un résultat préférable à une corruption du dépôt.\n\n\nAvec la sortie de Git 2.53, le rempaquetage géométrique fonctionne désormais avec les dépôts de clones partiels. Lors d'un rempaquetage géométrique, les fichiers d'empaquetage promisor sont gérés séparément afin de préserver le marqueur promisor et sont rempaquetés selon une progression géométrique distincte. Avec ce correctif, la stratégie géométrique suit une progression logique en vue de s'imposer comme la stratégie de rempaquetage par défaut. Pour plus d'informations, consultez le [fil de discussion de la liste de diffusion](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/) correspondant.\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n## git-fast-import(1) : préservation des signatures valides uniquement\n\n\nDans notre [article de blog consacré à la version Git 2.52](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-52-0/), nous avons abordé les améliorations liées aux signatures apportées à git-fast-import(1) et git-fast-export(1). Consultez cet article pour une explication plus détaillée de ces commandes, de leur utilisation et des modifications apportées concernant les signatures.\n\n\nPour résumer brièvement, git-fast-import(1) fournit un backend qui permet d'importer efficacement des données dans un dépôt et qui est utilisé par des outils tels que [git-filter-repo(1)](https://github.com/newren/git-filter-repo) pour aider à réécrire l'historique d'un dépôt en masse. Dans la version Git 2.52, git-fast-import(1) a appris l'option `--signed-commits=\u003Cmode>`, qui est similaire à la même option dans git-fast-export(1). Avec cette option, il est devenu possible de conserver ou de supprimer de façon inconditionnelle les signatures des commits et des tags.\n\n\nDans les situations où seule une partie de l'historique du dépôt a été réécrite, toute signature pour les commits ou tags réécrits devient invalide. Cela signifie que git-fast-import(1) est limité : la commande peut soit supprimer toutes les signatures, soit les conserver même si elles sont devenues invalides. Mais conserver des signatures invalides n'est pas vraiment utile, c'est pourquoi la réécriture de l'historique avec git-repo-filter(1) entraîne la suppression de toutes les signatures, même si le commit ou tag sous-jacent n'est pas réécrit. Cette approche n'est pas idéale : si le commit ou tag ne change pas, sa signature est toujours valide et il n'y a donc aucune raison réelle de la supprimer. Nous avons en réalité besoin de préserver les signatures pour les objets inchangés, et de supprimer les signatures invalides.\n\n\nAvec la sortie de Git 2.53, l'option `--signed-commits=\u003Cmode>` de git-fast-import(1) a appris un nouveau mode `strip-if-invalid` qui, lorsqu'il est utilisé, supprime seulement les signatures devenues invalides des commits réécrits. Ainsi, avec cette option, il devient possible de préserver certaines signatures de commits lors de l'utilisation de git-fast-import(1). Il s'agit d'une étape critique vers la mise en place des bases qui permettent à des outils comme git-repo-filter(1) de préserver les signatures valides et, plus tard, de signer à nouveau les signatures invalides.\n\n\nCe projet a été mené par [Christian Couder](https://gitlab.com/chriscool).\n\n\n## Plus de données collectées dans git-repo-structure\n\n\nDans la version Git 2.52, la sous-commande « structure » a été introduite dans git-repo(1). L'objectif de cette commande était de collecter des informations sur le dépôt et de remplacer éventuellement nativement des outils tels que [git-sizer(1)](https://github.com/github/git-sizer). Chez GitLab, nous hébergeons des dépôts extrêmement volumineux, et disposer d'informations sur la structure générale d'un dépôt est essentiel pour comprendre ses performances. Dans cette version, la commande collecte désormais également des informations sur la taille totale des objets accessibles dans un dépôt afin d'aider à comprendre la taille globale du dépôt. Dans les données de sortie ci-dessous, vous pouvez voir que la commande collecte désormais à la fois les tailles totales décompressées et sur disque des objets accessibles par type.\n\n```shell\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n```\n\n\nVous aurez peut-être également remarqué que les valeurs de taille dans le tableau des données de sortie sont désormais également affichées de manière plus conviviale avec des unités. Dans les versions suivantes, nous espérons étendre davantage les données de sortie de cette commande pour fournir des éléments supplémentaires, tels que les objets individuels les plus volumineux du dépôt.\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Pour en savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière version. Vous pouvez en apprendre davantage sur ces contributions dans l'[annonce de version officielle](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [articles de blog précédents sur les versions de Git](https://about.gitlab.com/fr-fr/blog/tags/git/) pour découvrir d'autres contributions des membres de l'équipe GitLab.","2026-02-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[762],"Justin Tobler","Découvrez les contributions à cette version, notamment les correctifs apportés au rempaquetage géométrique, une évolution des options de gestion des signatures de commits dans git-fast-import(1), et bien plus encore.","Nouveautés de Git 2.53.0",{"featured":33,"template":13,"slug":766},"whats-new-in-git-2-53-0",{"promotions":768},[769,783,795,807],{"id":770,"categories":771,"header":773,"text":774,"button":775,"image":780},"ai-modernization",[772],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":776,"config":777},"Get your AI maturity score",{"href":778,"dataGaName":779,"dataGaLocation":254},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":781},{"src":782},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":784,"categories":785,"header":787,"text":774,"button":788,"image":792},"devops-modernization",[786,584],"product","Are you just managing tools or shipping innovation?",{"text":789,"config":790},"Get your DevOps maturity score",{"href":791,"dataGaName":779,"dataGaLocation":254},"/assessments/devops-modernization-assessment/",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":796,"categories":797,"header":799,"text":774,"button":800,"image":804},"security-modernization",[798],"security","Are you trading speed for security?",{"text":801,"config":802},"Get your security maturity score",{"href":803,"dataGaName":779,"dataGaLocation":254},"/assessments/security-modernization-assessment/",{"config":805},{"src":806},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":808,"paths":809,"header":812,"text":813,"button":814,"image":819},"github-azure-migration",[810,811],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":815,"config":816},"See how GitLab compares to GitHub",{"href":817,"dataGaName":818,"dataGaLocation":254},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":820},{"src":794},{"header":822,"blurb":823,"button":824,"secondaryButton":828},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":48,"config":825},{"href":826,"dataGaName":51,"dataGaLocation":827},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":53,"config":829},{"href":55,"dataGaName":56,"dataGaLocation":827},1777934834312]