Version de contrôle de source Git 2.38

La sortie du système de contrôle de source distribué Git 2.38 a été annoncée. 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 699 modifications préparées avec la participation de 92 développeurs, dont 24 ont participé au développement pour la première fois. Principales innovations :

  • La structure principale comprend l'utilitaire « scalaire », développé par Microsoft pour gérer de grands référentiels. L'utilitaire a été initialement écrit en C#, mais git inclut une version modifiée en C. Le nouvel utilitaire diffère de la commande git en activant par défaut des fonctionnalités et des paramètres supplémentaires qui affectent les performances lorsque vous travaillez avec de très grands référentiels. Par exemple, lors de l'utilisation de scalaire, cela s'applique :
    • Clonage partiel pour travailler avec une copie incomplète du référentiel.
    • Mécanisme intégré de suivi des modifications dans le système de fichiers (FSMonitor), qui vous permet de vous passer de chercher dans l'ensemble du répertoire de travail.
    • Index couvrant les objets dans différents fichiers pack (multi-pack).
    • fichiers commit-graph avec un index de graphique de validation utilisé pour optimiser l'accès aux informations de validation.
    • Travail périodique en arrière-plan pour maintenir la structure optimale du référentiel en arrière-plan, sans bloquer la session interactive (le travail est effectué une fois par heure pour télécharger de manière proactive de nouveaux objets à partir du référentiel distant et mettre à jour le fichier avec le graphique de validation, et le processus de compression le dépôt est démarré tous les soirs).
    • Mode "sparseCheckoutCone", qui limite les modèles autorisés lors du clonage partiel.
  • Ajout d'une option --update-refs à la commande "git rebase" pour mettre à jour les branches dépendantes qui chevauchent les branches en cours de déplacement, plutôt que d'avoir à extraire manuellement chaque branche dépendante pour passer à la validation requise.
  • Rendu la commande "git rm" compatible avec les index partiels.
  • Amélioration du comportement de la commande "git mv AB" lors du déplacement d'un fichier d'un espace de travail avec index partiels en mode "cône" vers un scope externe qui ne dispose pas de ce mode.
  • Le format de fichier bitmap a été optimisé pour travailler avec de grands référentiels - une table d'index facultative a été ajoutée avec une liste des commits sélectionnés et leurs décalages.
  • La commande « git merge-tree » implémente un nouveau mode dans lequel, sur la base de deux commits spécifiés, un arbre avec le résultat de la fusion est calculé, comme si les historiques de ces commits étaient fusionnés.
  • Ajout du paramètre "safe.barerepository" pour contrôler la possibilité d'héberger des référentiels nus (dépôts qui ne contiennent pas d'arborescence de travail) dans d'autres référentiels git. Lorsqu'il est défini sur « explicite », il sera possible de travailler avec des référentiels nus situés uniquement dans le répertoire supérieur. Pour pouvoir placer des référentiels nus dans des sous-répertoires, utilisez la valeur « all ».
  • La commande « git grep » a ajouté l'option « -m » (« —max-count »), qui est similaire à l'option du même nom dans GNU grep et permet de limiter le nombre de correspondances affichées.
  • La commande « ls-files » implémente l'option « --format » pour configurer les champs de sortie (par exemple, vous pouvez activer la sortie du nom de l'objet, des modes, etc.).
  • Dans « git cat-file », lors de l'affichage du contenu des objets, il est possible de prendre en compte les liaisons auteur-email spécifiées dans le fichier mailmap.

Source: opennet.ru

Ajouter un commentaire