sortie d'un système de contrôle de source distribué . Git est l'un des systèmes de contrôle de versions les plus populaires, les plus fiables et les plus performants, fournissant des outils de développement non linéaires flexibles basés sur le branchement et la fusion. Pour garantir l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de l'intégralité de l'historique précédent dans chaque commit est utilisé, et il est également possible de certifier des balises et des commits individuels avec les signatures numériques des développeurs.
Par rapport à la version précédente, la nouvelle version comprenait 745 modifications préparées avec la participation de 74 développeurs, dont 18 ont participé au développement pour la première fois. :
- Disponible depuis la version 1.18, le nouveau mode de rebase de commit "git rebase --rebase-merges" remplace l'ancienne option "--preserve-merges", qui est désormais obsolète. L'opération "git rebase" est utilisée pour remplacer une série de commits par un nouveau commit de base, par exemple pour déplacer une branche distincte qui développe une nouvelle fonctionnalité vers l'état actuel de la branche principale, qui inclut les correctifs ajoutés après la branche. :
o - o - o (ma fonctionnalité)
/
o - o - o - o - o (maître)
o - o - o (ma fonctionnalité)
/
o - o - o - o - o (maître)
Pour préserver la structure des branches dans une branche migrée, l'option « --preserve-merges » pouvait auparavant être utilisée, qui, lorsqu'elle était exécutée en mode interactif (git rebase -i --preserve-merges), permettait de modifier l'historique des validations, mais ne garantissait pas la préservation complète de la structure du dépôt. Le nouveau mode « --rebase-merges » vous permet de conserver la structure des modifications dans la branche en cours de migration, tout en offrant une gamme complète d'opérations interactives, notamment la suppression, le regroupement et le renommage des commits.
Par exemple, "--rebase-merges" téléchargez à nouveau les commits d'une branche distincte vers une branche principale plus récente, tout en conservant la structure de branche dans la branche migrée, et apportez quelques modifications aux notes de commit à la volée.
- Ajout du support pour créer une nouvelle branche basée sur le résultat de la détermination de la base de fusion de deux autres branches (base de fusion, liaison à un ancêtre commun) en utilisant les constructions « git branch new A...B » et « git checkout -b new A...B", dans lequel "A ...B" implique de définir une base de fusion entre deux commits spécifiés, de la même manière que "git checkout A...B" déplace le HEAD vers le commit de base et "diff A. ..B" montre les changements entre le commit "B" et le même que le commit "A" "Ancestor.
Par exemple, lorsque vous travaillez sur une branche my-feature distincte, cette fonctionnalité peut être utilisée lorsque vous souhaitez démarrer à partir d'une branche différente, par exemple, du même endroit dans la branche master à partir de laquelle la branche my-feature a été extraite. Auparavant, cela nécessitait d'examiner manuellement le journal des modifications, ce qui n'était pas pratique si vous aviez un historique important de modifications, puis d'exécuter « git merge-base master my-feature » pour calculer le hachage de la base de fusion entre les branches master et my-feature. et créer une nouvelle branche par rapport à l'ancêtre commun « git branch my-other-feature hash ». Dans Git 2.22, vous pouvez utiliser la syntaxe « git branch my-other-feature A...B » pour créer une branche relative à la base de la fusion de deux autres branches ;
- Ajout de l'option "git branch --show-current" pour afficher le nom de la branche obtenue lors de l'opération de paiement ;
- Ajout de l'option « git checkout —no-overlay — dir », qui permet, lors d'une opération d'extraction, d'amener le contenu du répertoire dir sous une forme qui correspond entièrement à l'état de la branche master. Par exemple, s'il y a un fichier dans la copie locale du répertoire dir qui ne se trouve pas dans la branche master, alors par défaut lors de l'exécution de « git checkout master - dir », il sera laissé, et si le « --no-overlay " est spécifiée, elle sera supprimée ;
- La commande "git diff" utilise une API universelle pour analyser les options, ce qui permet d'unifier la gestion des options avec d'autres utilitaires git. Par exemple, dans « git diff », toutes les options ont désormais leurs antagonistes (« --function-context » et « --no-function-context ») ;
- Ajout de la possibilité de filtrer les balises étendues attachées aux commits dans la sortie « git log » (« bande-annonce » - indicateurs d'informations supplémentaires, tels que Signed-off-by et Co-authored-by). Il est possible de filtrer les étiquettes par clé et par valeur, par exemple :
"git log --pretty="%(trailers:key=Reviewed-by,valueonly)"; - Un nouveau moteur de traçage, Trace2, a été ajouté, offrant un format de sortie plus flexible et structuré. Trace2 vous permet de collecter des données télémétriques sur les opérations exécutées et les données de performances pour une analyse et un débogage plus détaillés (le gestionnaire est attribué par l'utilisateur, aucune donnée n'est envoyée en externe) ;
- Le rapport « git bisect » a été rendu plus lisible, dans lequel les commits problématiques sont désormais plus clairement mis en évidence et des statistiques récapitulatives des modifications pour chaque fichier sont affichées (au niveau du nombre de lignes modifiées) ;
- Les heuristiques permettant de déterminer les renommages de répertoires ont été retravaillées pour éliminer les fausses installations d'étiquettes de renommage. En cas de doute, ces répertoires sont désormais marqués comme étant en conflit ;
- Un avertissement s'affiche lorsque vous essayez d'installer une balise sur une autre balise, ce qui est généralement fait par erreur et peut conduire à définir la balise sur le mauvais commit (par exemple, une construction comme « git tag -f -m « message mis à jour » my-tag1 my-tag2″ entraînera la création d'une balise sur l'ancienne balise, alors que le développeur s'attendait à ce que la nouvelle balise soit installée sur le commit pointé par l'ancienne balise) ;
- La génération est activée pour les référentiels bitmap (structure « bitmaps d'accessibilité » basée sur disque), qui stockent des données sur les ensembles d'objets disponibles pour chaque validation et vous permettent de déterminer rapidement la présence d'un objet de base. Cette structure réduit considérablement le temps d'exécution des opérations de récupération de données (git fetch).
Source: opennet.ru