{"id":148781,"date":"2025-11-18T23:12:24","date_gmt":"2025-11-18T21:12:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52"},"modified":"2025-11-18T23:12:24","modified_gmt":"2025-11-18T21:12:24","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Publication du syst\u00e8me de gestion de versions Git 2.52","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s trois mois de d\u00e9veloppement, la version 2.52 du syst\u00e8me de gestion d\u00e9centralis\u00e9 de versions, Git, est pr\u00e9sent\u00e9e. Git se distingue par sa haute performance et offre des outils de d\u00e9veloppement non lin\u00e9aire bas\u00e9s sur la cr\u00e9ation et la fusion de branches. Pour garantir l'int\u00e9grit\u00e9 de l'historique et la r\u00e9silience face aux modifications \u00ab r\u00e9troactives \u00bb, un hachage implicite de toute l'histoire pr\u00e9c\u00e9dente est utilis\u00e9 dans chaque commit, ainsi que l'attestation par des signatures num\u00e9riques des d\u00e9veloppeurs pour certains tags et commits. Le code de Git est distribu\u00e9 sous la licence GPLv2+. <\/p>\n
Compar\u00e9e \u00e0 la version pr\u00e9c\u00e9dente, cette nouvelle version comprend 637 modifications, r\u00e9alis\u00e9es par 94 d\u00e9veloppeurs (33 ayant particip\u00e9 \u00e0 Git pour la premi\u00e8re fois). Les principales nouveaut\u00e9s (1, 2, 3) : <\/p>\n
\n
La commande \u00ab git last-modified \u00bb a \u00e9t\u00e9 ajout\u00e9e pour afficher une liste des fichiers dans la r\u00e9vision sp\u00e9cifi\u00e9e et des commits par lesquels les derni\u00e8res modifications ont \u00e9t\u00e9 apport\u00e9es \u00e0 chacun de ces fichiers. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c\n
La commande \u00ab git repo \u00bb a \u00e9t\u00e9 ajout\u00e9e pour effectuer des actions li\u00e9es \u00e0 l'extraction d'informations \u00e0 partir d'un d\u00e9p\u00f4t. Deux sous-commandes sont propos\u00e9es : \u00ab git repo info \u00bb et \u00ab git repo structure \u00bb, qui affichent des informations sur les param\u00e8tres du d\u00e9p\u00f4t et des d\u00e9tails sur la structure du d\u00e9p\u00f4t (par exemple, il est possible de conna\u00eetre le nombre de r\u00e9f\u00e9rences et d'objets dans le d\u00e9p\u00f4t). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Structure du d\u00e9p\u00f4t | Valeur | | \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014 | \u2014\u2014\u2014\u2014\u2014\u2014\u2014 | | * R\u00e9f\u00e9rences | | | * Compte | 1983 | | * Branches | 4 | | * Tags | 1125 | | * Remotes | 854 | | * Autres | 0 | | | | | * Objets accessibles | | | * Compte | 518955 | | * Commits | 77469 | | * Arbres | 188865 | | * Blobs | 251631 | | * Tags | 990 |\n
Trois sous-commandes ont \u00e9t\u00e9 ajout\u00e9es \u00e0 la commande \u00ab git refs \u00bb pour unifier les op\u00e9rations de bas niveau disparates et chevauchantes sur les r\u00e9f\u00e9rences (git for-each-ref, git show-ref, git update-ref et git pack-refs) :\n
\n
\u00ab git refs optimize \u00bb \u2014 optimisation de l'arri\u00e8re-plan de stockage des r\u00e9f\u00e9rences (similaire \u00e0 \u00ab git pack-refs \u00bb).\n
\u00ab git refs list \u00bb \u2014 affichage de la liste de toutes les r\u00e9f\u00e9rences (similaire \u00e0 \u00ab git for-each-ref \u00bb ou \u00ab git show-ref \u00bb).\n
\u00ab git refs exists \u00bb \u2014 v\u00e9rification de l'existence d'une r\u00e9f\u00e9rence (\u00e9quivalent \u00e0 \u00ab git show-ref \u2014exists \u00bb). <\/ul>\n
Le format d'exportation ou d'importation de l'historique des commits a \u00e9t\u00e9 \u00e9tendu pour permettre l'utilisation de signatures cryptographiques, utilisant \u00e0 la fois des identifiants d'objets bas\u00e9s sur l'algorithme SHA-1 et sur SHA-256. Dans la commande «git fast-import», le support du traitement des tags sign\u00e9s a \u00e9t\u00e9 mis en \u0153uvre, de mani\u00e8re analogue aux commits sign\u00e9s. Des options «—signed-commits=<mode>» et «—signed-tags=<mode>» ont \u00e9t\u00e9 ajout\u00e9es pour contr\u00f4ler le traitement des commits et des tags sign\u00e9s au moment de l'importation (le mode peut prendre les valeurs verbatim, warn-verbatim, warn-stri, strip ou abort).\n
La commande «git maintenance» a \u00e9t\u00e9 enrichie d'une nouvelle strat\u00e9gie «geometric» («git config set maintenance.strategy geometric»), permettant de r\u00e9duire le temps de maintenance des grands monorepo. Compar\u00e9e \u00e0 la strat\u00e9gie pr\u00e9c\u00e9dente, qui utilisait la logique de la commande «git gc», la nouvelle strat\u00e9gie \u00e9vite la r\u00e9emballage de tous les objets et exclut les op\u00e9rations trop gourmandes en ressources, comme la fusion de tous les fichiers pack (lorsque cela est possible, la fusion s'effectue par parties, sans nettoyer les objets supprim\u00e9s).\n
La commande «git sparse-checkout clean» a \u00e9t\u00e9 ajout\u00e9e pour faciliter la restauration de l'\u00e9tat du r\u00e9pertoire de travail, en supprimant les fichiers qui ne correspondent pas \u00e0 la nouvelle d\u00e9finition de sparse-checkout, qui ne devraient pas \u00eatre pr\u00e9sents dans la copie locale selon les param\u00e8tres actuels de sparse-checkout.\n
Pour all\u00e9ger la base de code et simplifier la maintenance, un refactoring a \u00e9t\u00e9 effectu\u00e9 pour r\u00e9duire l'utilisation de la variable globale the_repository.\n
L'application des filtres de Bloom a \u00e9t\u00e9 \u00e9tendue, une structure probabiliste pour v\u00e9rifier l'appartenance \u00e0 un ensemble, qui admet une fausse identification d'\u00e9l\u00e9ments manquants, mais exclut le risque de laisser passer un \u00e9l\u00e9ment existant. Les filtres de Bloom sont d\u00e9sormais utilis\u00e9s pour acc\u00e9l\u00e9rer la recherche dans l'historique des modifications en sp\u00e9cifiant des masques dans les chemins de fichiers, par exemple, «foo\/bar\/*\/baz».\n
Les performances de la commande «git describe» ont \u00e9t\u00e9 am\u00e9lior\u00e9es de 30 %, gr\u00e2ce \u00e0 l'utilisation d'une file d'attente prioritaire. Dans «git remote rename», les op\u00e9rations de renommage des r\u00e9f\u00e9rences ont \u00e9t\u00e9 acc\u00e9l\u00e9r\u00e9es. Dans «git ls-files», l'application des index a \u00e9t\u00e9 \u00e9largie. L'ex\u00e9cution de la commande «git log -L» a \u00e9t\u00e9 consid\u00e9rablement acc\u00e9l\u00e9r\u00e9e, gr\u00e2ce \u00e0 l'\u00e9limination de comparaisons inappropri\u00e9es \u00e0 trois niveaux lors du traitement des fusions de commits. Des optimisations ont \u00e9t\u00e9 apport\u00e9es \u00e0 la biblioth\u00e8que xdiff.\n
Il est d\u00e9sormais possible d'utiliser des implementations en Rust pour certaines fonctions internes, telles que l'encodage et le d\u00e9codage des valeurs enti\u00e8res de longueur variable. Par d\u00e9faut, le code Rust n'est pas utilis\u00e9 et n\u00e9cessite d'activer l'option de compilation WITH_RUST. \u00c0 l'avenir, on s'attend \u00e0 ce que des composants internes significatifs de Git soient r\u00e9\u00e9crits en Rust et que Rust devienne une d\u00e9pendance de compilation requise dans Git 3.0.\n
La liste des modifications non compatibles a \u00e9t\u00e9 mise \u00e0 jour pour la branche Git 3.0. Dans Git 3.0, il a \u00e9t\u00e9 d\u00e9cid\u00e9 de changer la configuration de init.defaultBranch par d\u00e9faut \u00e0 «main», c'est-\u00e0-dire que dans les d\u00e9p\u00f4ts cr\u00e9\u00e9s avec la commande «git init», la branche par d\u00e9faut sera nomm\u00e9e «main», et non «master». Il est \u00e9galement not\u00e9 que la transition par d\u00e9faut vers des identifiants d'objets bas\u00e9s sur l'algorithme de hachage SHA-256 lors de l'initialisation de nouveaux d\u00e9p\u00f4ts est en cours. Pour simplifier la portabilit\u00e9 entre les d\u00e9p\u00f4ts avec des identifiants d'objets bas\u00e9s sur des hachages SHA-1 et SHA-256, il est d\u00e9sormais possible dans un d\u00e9p\u00f4t utilisant un seul algorithme de hachage d'effectuer des op\u00e9rations de push et pull \u00e0 partir d'un d\u00e9p\u00f4t utilisant un autre algorithme de hachage. <\/ul>\n