{"id":103093,"date":"2022-01-25T15:36:40","date_gmt":"2022-01-25T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35"},"modified":"2022-01-25T15:36:40","modified_gmt":"2022-01-25T13:36:40","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","title":{"rendered":"Publication du syst\u00e8me de gestion de versions Git 2.35.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s deux mois de d\u00e9veloppement, la version du syst\u00e8me de gestion de version distribu\u00e9e Git 2.35 a \u00e9t\u00e9 publi\u00e9e. Git est l'un des syst\u00e8mes de gestion de version les plus populaires, fiables et performants, offrant des outils flexibles de d\u00e9veloppement non lin\u00e9aire bas\u00e9s sur le ramification et la fusion de branches. Pour garantir l'int\u00e9grit\u00e9 de l'historique et la r\u00e9sistance aux modifications \u00ab r\u00e9troactives \u00bb, un hachage implicite de tout l'historique pr\u00e9c\u00e9dent est utilis\u00e9 dans chaque commit ; il est \u00e9galement possible de certifier num\u00e9riquement les balises et commits des d\u00e9veloppeurs. <\/p>\n
Compar\u00e9 \u00e0 la version pr\u00e9c\u00e9dente, 494 modifications ont \u00e9t\u00e9 int\u00e9gr\u00e9es dans cette nouvelle version, pr\u00e9par\u00e9es avec la participation de 93 d\u00e9veloppeurs, dont 35 ont particip\u00e9 pour la premi\u00e8re fois au d\u00e9veloppement. Les principales nouveaut\u00e9s : <\/p>\n
\n
Les fonctionnalit\u00e9s concernant l'utilisation des cl\u00e9s SSH pour certifier num\u00e9riquement les objets Git ont \u00e9t\u00e9 \u00e9tendues. Pour faire la distinction entre la dur\u00e9e de validit\u00e9 de plusieurs cl\u00e9s, le support des directives OpenSSH \u00ab valid-before \u00bb et \u00ab valid-after \u00bb a \u00e9t\u00e9 ajout\u00e9, permettant ainsi d'assurer un fonctionnement correct avec les signatures apr\u00e8s la rotation de la cl\u00e9 d'un des d\u00e9veloppeurs. Auparavant, il y avait un probl\u00e8me de partage des signatures entre une ancienne et une nouvelle cl\u00e9 : si l'ancienne cl\u00e9 \u00e9tait supprim\u00e9e, il devenait impossible de v\u00e9rifier les signatures r\u00e9alis\u00e9es avec elle, et si elle \u00e9tait conserv\u00e9e, il restait possible de cr\u00e9er de nouvelles signatures avec cette ancienne cl\u00e9, alors qu'une autre cl\u00e9 l'avait d\u00e9j\u00e0 remplac\u00e9e. Gr\u00e2ce \u00e0 valid-before et valid-after, il est possible de d\u00e9limiter le champ d'application des cl\u00e9s en fonction de la date de cr\u00e9ation de la signature.\n
Dans la configuration merge.conflictStyle, permettant de choisir le mode de pr\u00e9sentation des informations de conflit lors de la fusion, un nouveau mode \u00ab zdiff3 \u00bb a \u00e9t\u00e9 ajout\u00e9. Ce mode d\u00e9place toutes les lignes standard figurant au d\u00e9but ou \u00e0 la fin d'un conflit en dehors de la zone de conflit, permettant ainsi d'obtenir une repr\u00e9sentation plus compacte des informations.\n
La commande \u00ab git stash \u00bb a \u00e9t\u00e9 enrichie d'un mode \u00ab --staged \u00bb, qui permet de cacher uniquement les modifications ajout\u00e9es \u00e0 l'index. Cela est utile dans les situations o\u00f9 il est n\u00e9cessaire de reporter temporairement une partie de modifications complexes pour d'abord ajouter ce qui est d\u00e9j\u00e0 pr\u00eat, et de revenir au reste plus tard. Ce mode ressemble \u00e0 la commande \u00ab git commit \u00bb, qui enregistre uniquement les modifications plac\u00e9es dans l'index, mais au lieu de cr\u00e9er un nouveau commit, \u00ab git stash --staged \u00bb sauvegarde le r\u00e9sultat dans une zone temporaire de stash. Une fois les modifications n\u00e9cessaires, elles peuvent \u00eatre retourn\u00e9es avec la commande \u00ab git stash pop \u00bb.\n
Une nouvelle sp\u00e9cification de format «--format=%(describe)» a \u00e9t\u00e9 ajout\u00e9e \u00e0 la commande «git log», permettant de combiner la sortie de «git log» avec le r\u00e9sultat de l'ex\u00e9cution de la commande «git describe». Les param\u00e8tres pour «git describe» sont sp\u00e9cifi\u00e9s directement \u00e0 l'int\u00e9rieur de la sp\u00e9cification («--format=%(describe:match=<foo>,exclude=<bar>)»), o\u00f9 il est \u00e9galement possible d'inclure des tags abr\u00e9g\u00e9s («--format=%(describe:tags=<bool>)») et de configurer le nombre de caract\u00e8res hexad\u00e9cimaux pour identifier les objets («--format=%(describe:abbrev=<n>)»). Par exemple, pour afficher les 8 derniers commits dont les tags n'ont pas d'\u00e9tiquette candidate pour la version, avec des identifiants de 8 caract\u00e8res, on peut utiliser la commande : $ git log -8 —format=’%(describe:exclude=*-rc*,abbrev=13)’ v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132\n
La configuration de user.signingKey prend d\u00e9sormais en charge de nouveaux types de cl\u00e9s, ne se limitant pas au type «ssh-» et \u00e0 la sp\u00e9cification du chemin complet vers la cl\u00e9. Les types alternatifs sont d\u00e9finis \u00e0 l'aide du pr\u00e9fixe «key::», par exemple, «key::ecdsa-sha2-nistp256» pour les cl\u00e9s ECDSA.\n
La vitesse de g\u00e9n\u00e9ration de la liste des changements en mode «--histogram» a \u00e9t\u00e9 consid\u00e9rablement am\u00e9lior\u00e9e, ainsi que lors de l'utilisation de l'option «--color-moved-ws», qui contr\u00f4le la mise en surbrillance des espaces dans les diff color\u00e9s.\n
La commande «git jump», utilis\u00e9e pour fournir \u00e0 Vim des informations sur les transitions exactes vers une position recherch\u00e9e dans un fichier lors de la r\u00e9solution des conflits de fusion, de la visualisation des diff\u00e9rences ou de l'ex\u00e9cution d'une recherche, a \u00e9t\u00e9 am\u00e9lior\u00e9e pour affiner la couverture des conflits de fusion. Par exemple, pour restreindre les op\u00e9rations uniquement au r\u00e9pertoire «foo», vous pouvez sp\u00e9cifier «git jump merge — foo», et pour exclure le r\u00e9pertoire «Documentation», utiliser «git jump merge ‘:^Documentation'».\n
Un effort a \u00e9t\u00e9 entrepris pour standardiser l'utilisation du type «size_t» au lieu de «unsigned long» pour les valeurs repr\u00e9sentant la taille des objets, ce qui a permis d'utiliser les filtres «clean» et «smudge» avec des fichiers de plus de 4 Go sur toutes les plateformes, y compris celles utilisant le mod\u00e8le de donn\u00e9es LLP64, o\u00f9 le type «unsigned long» est limit\u00e9 \u00e0 4 octets.\n
La commande «git am» a \u00e9t\u00e9 dot\u00e9e de l'option «—empty=(stop|drop|keep)», permettant, lors de l'analyse des patches \u00e0 partir d'une bo\u00eete mail, de choisir le comportement pour les messages vides ne contenant pas de patches. La valeur «stop» entra\u00eenera l'arr\u00eat de toute l'op\u00e9ration d'application des patches, «drop» ignorera le patch vide, «keep» cr\u00e9era un commit vide.\n
Les commandes «git reset», «git diff», «git blame», «git fetch», «git pull» et «git ls-files» ont \u00e9t\u00e9 mises \u00e0 jour pour prendre en charge les index partiels (sparse index), permettant d'am\u00e9liorer les performances et de gagner de la place dans les d\u00e9p\u00f4ts pour lesquels des op\u00e9rations de clonage partiel (sparse-checkout) sont effectu\u00e9es.\n
La commande «git sparse-checkout init» a \u00e9t\u00e9 d\u00e9clar\u00e9e obsol\u00e8te, il faut d\u00e9sormais utiliser «git sparse-checkout set».\n
Une impl\u00e9mentation initiale du nouveau backend «reftable» pour le stockage des r\u00e9f\u00e9rences, telles que les branches et les tags, dans le d\u00e9p\u00f4t a \u00e9t\u00e9 ajout\u00e9e. Ce nouveau backend utilise un stockage en blocs, utilis\u00e9 par le projet JGit, et est optimis\u00e9 pour stocker un tr\u00e8s grand nombre de r\u00e9f\u00e9rences. Le backend n'est pas encore int\u00e9gr\u00e9 au syst\u00e8me de r\u00e9f\u00e9rences (refs) et n'est pas pr\u00eat pour une utilisation pratique.\n
La palette de couleurs de la commande «git grep» a \u00e9t\u00e9 harmonis\u00e9e avec l'outil GNU grep. <\/ul>\n