{"id":141016,"date":"2025-08-19T11:11:54","date_gmt":"2025-08-19T09:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51"},"modified":"2025-08-19T11:11:54","modified_gmt":"2025-08-19T09:11:54","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Publication du syst\u00e8me de gestion de version Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s deux mois de d\u00e9veloppement, une version du syst\u00e8me distribu\u00e9 de gestion des fichiers source Git 2.51 a \u00e9t\u00e9 publi\u00e9e. Git se distingue par sa haute performance et offre des outils pour un d\u00e9veloppement non lin\u00e9aire bas\u00e9 sur le branchement et la fusion de branches. Pour garantir l'int\u00e9grit\u00e9 de l'historique et sa r\u00e9sistance aux modifications \u00ab r\u00e9troactives \u00bb, Git utilise un hachage implicite de toute l'histoire pr\u00e9c\u00e9dente dans chaque commit, ainsi que la certification par des signatures num\u00e9riques des d\u00e9veloppeurs pour les balises et commits individuels. Le code de Git est distribu\u00e9 sous licence GPLv2+. <\/p>\n
Compar\u00e9e \u00e0 la version pr\u00e9c\u00e9dente, la nouvelle version inclut 506 modifications effectu\u00e9es par 91 d\u00e9veloppeurs (dont 21 ont particip\u00e9 au d\u00e9veloppement de Git pour la premi\u00e8re fois). Les principales nouveaut\u00e9s (1, 2, 3) : <\/p>\n
\n
La performance des commandes \u00ab git push \u00bb et \u00ab git fetch \u00bb a \u00e9t\u00e9 am\u00e9lior\u00e9e dans les d\u00e9p\u00f4ts contenant un grand nombre de r\u00e9f\u00e9rences. L'acc\u00e9l\u00e9ration est due \u00e0 la mise \u00e0 jour des r\u00e9f\u00e9rences en mode batch, o\u00f9 plusieurs r\u00e9f\u00e9rences sont trait\u00e9es dans une seule transaction, au lieu de cr\u00e9er une transaction distincte pour chaque r\u00e9f\u00e9rence. Cette optimisation a consid\u00e9rablement augment\u00e9 la vitesse du backend \u00ab reftable \u00bb, qui d\u00e9passe d\u00e9sormais en performance le backend \u00ab files \u00bb. Par exemple, dans un d\u00e9p\u00f4t test avec 10 000 r\u00e9f\u00e9rences, la performance de \u00ab git fetch \u00bb avec le backend \u00ab reftable \u00bb a augment\u00e9 de 22 fois, tandis qu'avec le backend \u00ab files \u00bb, elle a augment\u00e9 de 1,25 fois. Pour \u00ab git push \u00bb, l'augmentation \u00e9tait de 18 et 1,21 fois, respectivement.\n
Une nouvelle m\u00e9thode d'emballage dans les fichiers pack des parties du d\u00e9p\u00f4t non li\u00e9es au suivi d'objets inaccessibles, sur lesquels il n'existe pas de r\u00e9f\u00e9rences (aucun branchement ou balise), a \u00e9t\u00e9 propos\u00e9e. Les informations sur les objets inaccessibles sont conserv\u00e9es dans des fichiers pack s\u00e9par\u00e9s (\u00ab cruft packs \u00bb), ce qui entra\u00eenait la n\u00e9cessit\u00e9 de les refl\u00e9ter dans les index multi-pack MIDX (multi-pack index) pour inclure les objets qui \u00e9taient initialement inaccessibles et conserv\u00e9s uniquement dans le pack cruft, mais qui sont devenus accessibles apr\u00e8s un commit qui y fait r\u00e9f\u00e9rence.\n
Dans la nouvelle version, lors de la r\u00e9emballage des fichiers pack, il est garanti que des copies suppl\u00e9mentaires d'objets accessibles, conserv\u00e9es uniquement dans des fichiers cruft, sont sauvegard\u00e9es. Ce changement garantit qu'aucun objet r\u00e9f\u00e9rentiel vers d'autres objets, stock\u00e9s en dehors de cet ensemble, ne figure dans le jeu de fichiers pack utilis\u00e9 pour conserver des objets accessibles. Pour exclure le contenu inaccessible des fichiers cruft des index multi-pack (MIDX), une option appel\u00e9e \u00ab repack.MIDXMustContainCruft \u00bb a \u00e9t\u00e9 propos\u00e9e, permettant de r\u00e9duire consid\u00e9rablement la taille de ces index. L'activation de cette option dans le d\u00e9p\u00f4t GitHub a permis de diminuer de 38% la taille des index MIDX, d'acc\u00e9l\u00e9rer l'\u00e9criture dans les index MIDX de 35% et d'am\u00e9liorer les performances de lecture de 5%. <\/p>\n
La commande \u00ab git pack-objects \u00bb a \u00e9t\u00e9 dot\u00e9e d'une option \u00ab --path-walk \u00bb, qui introduit une nouvelle m\u00e9thode de collecte d'informations sur les objets lors de la r\u00e9emballage des fichiers pack. Au lieu de parcourir les objets dans l'ordre des r\u00e9visions, en utilisant le mode \u00ab --path-walk \u00bb, les objets sont parcourus via les chemins de fichiers, permettant d'emballer tous les objets avec le m\u00eame chemin de fichier en une seule fois. Cette approche permet d'\u00e9liminer l'heuristique qui utilise le hachage pour \u00e9tablir la relation entre un objet et son chemin de fichier, tout en supprimant le tri des objets avant l'emballage. En utilisant le mode \u00ab --path-walk \u00bb, la taille des fichiers pack g\u00e9n\u00e9r\u00e9s est consid\u00e9rablement inf\u00e9rieure \u00e0 celle obtenue par la mise en groupe des objets \u00e0 l'aide de hachages.\n
Un format pour l'\u00e9change des \u00e9tats sauvegard\u00e9s de l'arborescence de travail et des index dans le d\u00e9p\u00f4t, cr\u00e9\u00e9s \u00e0 l'aide de la commande \u00ab git stash \u00bb, a \u00e9t\u00e9 d\u00e9fini. Ce nouveau format permet d'encoder les modifications sauvegard\u00e9es (enregistrements stash) sous forme de s\u00e9quence de commits. Les sous-commandes \u00ab git stash import \u00bb et \u00ab git stash export \u00bb ont \u00e9t\u00e9 propos\u00e9es pour l'importation et l'exportation, qui peuvent \u00eatre utilis\u00e9es pour transf\u00e9rer des \u00e9tats sauvegard\u00e9s d'un syst\u00e8me \u00e0 un autre et effectuer des op\u00e9rations push ou pull avec ces \u00e9tats comme s'ils \u00e9taient des branches ou des tags ordinaires. git stash export --to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash \u2026 git fetch origin '+refs\/stashes\/*:refs\/stashes\/*' git stash import refs\/stashes\/my-stash\n
Dans l'\u00e9quipe \u00ab git cat-file \u00bb, qui affiche le contenu des objets sp\u00e9cifi\u00e9s, l'utilisation des options \u00ab --batch \u00bb et \u00ab --batch-check \u00bb a permis d'afficher des informations sur les objets manquants (par exemple, en raison d'une corruption du d\u00e9p\u00f4t) et des sous-modules. Auparavant, lors de la sp\u00e9cification du chemin d'un sous-module, la commande \u00ab git cat-file --batch-check \u00bb affichait \u00ab missing \u00bb, mais maintenant elle montrera l'identifiant de l'objet.\n
La commande \u00ab git log \u00bb utilise des optimisations bas\u00e9es sur des filtres de Bloom pour acc\u00e9l\u00e9rer la recherche dans l'historique des modifications lors de la sp\u00e9cification de filtres avec plusieurs chemins de fichiers, par exemple, \u00ab git log -- path\/to\/a path\/to\/b \u00bb.\n
Les commandes \u00ab git switch \u00bb et \u00ab git restore \u00bb ont \u00e9t\u00e9 stabilis\u00e9es, apr\u00e8s avoir \u00e9t\u00e9 consid\u00e9r\u00e9es comme exp\u00e9rimentales depuis 2019. Ces commandes sont pr\u00e9sent\u00e9es comme les \u00e9quivalents modernes de \u00ab git checkout \u00bb, s\u00e9parant des capacit\u00e9s peu li\u00e9es de cette commande, telles que la manipulation des branches (changement et cr\u00e9ation) et la restauration des fichiers dans le r\u00e9pertoire de travail.\n
La commande \u00ab git whatchanged \u00bb, \u00e9quivalente \u00e0 \u00ab git log --raw \u00bb, est d\u00e9clar\u00e9e obsol\u00e8te et pr\u00e9vue pour suppression dans la branche Git 3.0.\n
L'option \u00ab --start-after \u00bb a \u00e9t\u00e9 ajout\u00e9e \u00e0 la commande \u00ab git for-each-ref \u00bb, qui peut \u00eatre utilis\u00e9e avec l'option \u00ab --count \u00bb pour organiser la sortie pagin\u00e9e.\n
Les commandes \u00ab git merge \u00bb et \u00ab git pull \u00bb ont \u00e9t\u00e9 enrichies de l'option \u00ab --compact-summary \u00bb, permettant d'utiliser un format compact pour le r\u00e9sum\u00e9 des modifications au lieu du format diffstat.\n
L'utilisation du mot-cl\u00e9 \u00ab bool \u00bb, introduit dans la norme C99, est d\u00e9sormais autoris\u00e9e dans la base de code Git. Certaines fonctionnalit\u00e9s de C99, utilis\u00e9es exp\u00e9rimentalement dans Git, ont \u00e9galement \u00e9t\u00e9 document\u00e9es (par exemple, il est pr\u00e9vu de permettre l'utilisation des constructions \u00ab (struct foo){ .member = value }; \u00bb d'ici mi-2026). Un compilateur prenant en charge C99 est requis pour Git depuis 2021, mais les fonctionnalit\u00e9s de la sp\u00e9cification C99 sont impl\u00e9ment\u00e9es avec une grande prudence pour maintenir la compatibilit\u00e9 avec des compilateurs ne prenant en charge que partiellement cette norme.\n
Des modifications ont \u00e9t\u00e9 apport\u00e9es aux r\u00e8gles d'acceptation des patches, permettant l'envoi de patches sous un pseudonyme et non seulement sous le vrai nom du d\u00e9veloppeur. Ce changement est conforme aux r\u00e8gles d'acceptation des patches dans le noyau Linux.\n
La liste des modifications incompatibles a \u00e9t\u00e9 mise \u00e0 jour et sera appliqu\u00e9e dans la branche Git 3.0. Parmi les changements significatifs dans la prochaine version de Git 3.0, on note le passage par d\u00e9faut aux identifiants d'objets bas\u00e9s sur l'algorithme de hachage SHA-256 lors de l'initialisation de nouveaux d\u00e9p\u00f4ts, ainsi que l'utilisation du format \u00ab reftable \u00bb pour stocker les r\u00e9f\u00e9rences aux branches et tags dans le d\u00e9p\u00f4t (avec un stockage en bloc provenant du projet JGit, optimis\u00e9 pour g\u00e9rer un tr\u00e8s grand nombre de r\u00e9f\u00e9rences). <\/ul>\n