Sortie du système de gestion de version distribué Git 2.22

Présenté lancement d'un système de gestion décentralisé des textes sources Git 2.22.0. Git est l'un des systèmes de gestion de version les plus populaires, fiables et performants, offrant des outils flexibles pour le développement non linéaire, basés sur le branchement et la fusion de branches. Pour garantir l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de toute l'histoire précédente est utilisé dans chaque commit ; la vérification par des signatures numériques des développeurs est également possible pour certains tags et commits.

Par rapport à la version précédente, la nouvelle version comprend 745 modifications préparées par 74 développeurs, parmi lesquels 18 ont participé au développement pour la première fois. Principales nouveautés:

• Disponible depuis la version 1.18, le nouveau mode de transfert de la série de commits « git rebase --rebase-merges » remplace l'ancienne option « --preserve-merges », désormais marquée comme 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 où se développe une nouvelle fonctionnalité vers l'état actuel de la branche master, intégrant des corrections ajoutées après la divergence :

  o — o — o (my-feature)

  /

  o — o — o — o — o (master)

  o — o — o (my-feature)

  /

  o — o — o — o — o (master)

  Pour conserver la structure de ramification dans la branche transférable, l'option « --preserve-merges » pouvait être utilisée précédemment, permettant lors d'une exécution en mode interactif (git rebase -i --preserve-merges) de modifier l'historique des commits, mais sans garantir la conservation complète de la structure du dépôt. Le nouveau mode « --rebase-merges » permet de conserver la structure des changements dans la branche transférable, tout en offrant un ensemble complet d'opérations interactives, y compris la suppression, le regroupement et le renommage des commits.

  Par exemple, « --rebase-merges » d'installer retransférer des commits d'une branche séparée sur une branche master plus récente, tout en conservant la structure de ramification dans la branche transférable et en apportant en cours de route quelques modifications aux notes des commits.

• Ajout de la prise en charge de la création d'une nouvelle branche basée sur le résultat de la définition de la base de fusion de deux autres branches (merge base, référence à un ancêtre commun) à l'aide des constructions « git branch new A…B » et « git checkout -b new A…B », où « A…B » sous-entend la définition de la base de fusion entre deux commits spécifiés, de la manière dont « git checkout A…B » déplace HEAD vers le commit de base et « diff A…B » montre les changements entre le commit « B » et l’ancêtre commun avec le commit « A ».

  Par exemple, lors du travail sur une branche distincte my-feature, la fonctionnalité proposée peut être utilisée lorsqu'il est nécessaire de commencer à partir d'une autre branche, par exemple, à partir du même point dans la branche master d'où la branche my-feature a été extraite. Auparavant, il était nécessaire d'examiner manuellement le journal des modifications, ce qui posait des problèmes en cas de longue histoire de modifications, puis 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 avec «git branch my-other-feature haché». Dans Git 2.22, pour créer une branche par rapport à la base de fusion de deux autres branches, on peut utiliser la syntaxe «git branch my-other-feature A…B»;

• Ajout de l'option «git branch —show-current» pour afficher le nom de la branche obtenue après l'exécution de l'opération checkout;
• Ajout de l'option «git checkout —no-overlay — dir», permettant lors de l'opération checkout de faire correspondre le contenu du répertoire dir à l'état de la branche master. Par exemple, si dans la copie locale du répertoire dir il y a un fichier absent dans la branche master, par défaut lors de l'exécution de «git checkout master — dir» il sera laissé, et avec l'option «—no-overlay» il sera supprimé;
• Dans la commande «git diff», une API universelle a été mise en œuvre pour analyser les options, ce qui a permis de uniformiser le traitement des options avec d'autres utilitaires git. Par exemple, dans «git diff», tous les antagonistes pour toutes les options sont maintenant disponibles («—function-context» et «—no-function-context»);
• Ajout de la possibilité de filtrage lors de l'affichage de «git log» des étiquettes étendues attachées aux commits («trailer» - informations supplémentaires, telles que Signed-off-by et Co-authored-by). Un filtrage des étiquettes est possible tant par clé que par valeur, par exemple :
  «git log —pretty=»%(trailers:key=Reviewed-by,valueonly)»;
• Ajout d'un nouveau mécanisme de traçage Trace2, offrant un format de sortie plus flexible et structuré. Trace2 permet de collecter des télémetries sur les opérations exécutées et des données de performance 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 à l'extérieur);
• Le rapport «git bisect» est devenu plus lisible, mettant maintenant plus clairement en évidence les commits problématiques et affichant des statistiques résumées sur les modifications pour chaque fichier (au niveau du nombre de lignes modifiées);
• L'heuristique pour déterminer les renommages de répertoires a été retravaillée afin d'exclure les faux marquages de renommage. En cas de doute, ces répertoires sont désormais marqués comme conflictuels;
• Un avertissement est généré lors de la tentative d'ajouter une étiquette à une autre étiquette, ce qui se produit généralement par erreur et peut entraîner l'ajout d'un marqueur au mauvais commit (par exemple, la commande « git tag -f -m « updated message » my-tag1 my-tag2 » entraînera la création d'une étiquette sur une ancienne étiquette, alors que le développeur s'attendait à ce que la nouvelle étiquette soit appliquée au commit pointé par l'ancienne étiquette);
• La génération de bitmap pour les référentiels (structure de données « reachability bitmaps »), qui conserve des informations sur les ensembles d'objets accessibles pour chaque commit, a été activée, permettant 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