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 tout l'historique précédent est utilisé dans chaque commit ; 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 504 modifications préparées avec la participation de 64 développeurs, dont 12 ont participé au développement pour la première fois. :
- La valeur par défaut a été changée en Protocole de communication Git, utilisé lorsqu'un client se connecte à distance à un serveur Git. La deuxième version du protocole se distingue par la possibilité de filtrer les branches et les balises côté serveur, renvoyant une liste raccourcie de liens au client. Auparavant, toute commande pull envoyait toujours au client la liste complète des références dans l'ensemble du référentiel, même lorsque le client ne mettait à jour qu'une branche ou vérifiait que sa copie du référentiel était à jour. Une autre innovation notable est la possibilité d’ajouter de nouvelles capacités au protocole à mesure que de nouvelles fonctionnalités deviennent disponibles dans la boîte à outils. Le code client reste compatible avec l'ancien protocole et peut continuer à fonctionner avec les nouveaux et les anciens serveurs, en revenant automatiquement à la première version si le serveur ne prend pas en charge la seconde.
- L'option « -show-scope » a été ajoutée à la commande « git config », permettant d'identifier plus facilement l'endroit où certains paramètres sont définis. Git vous permet de définir des paramètres à différents endroits : dans le référentiel (.git/info/config), dans le répertoire utilisateur (~/.gitconfig), dans le fichier de configuration à l'échelle du système (/etc/gitconfig) et via la commande options de ligne et variables d’environnement. Lors de l’exécution de « git config », il est assez difficile de comprendre où exactement le paramètre souhaité est défini. Pour résoudre ce problème, l'option « --show-origin » était disponible, mais elle affiche uniquement le chemin d'accès au fichier dans lequel le paramètre est défini, ce qui est utile si vous avez l'intention de modifier le fichier, mais n'aide pas si vous vous devez modifier la valeur via « git config » en utilisant les options « --system », « --global » ou « -local ». La nouvelle option "--show-scope" affiche le contexte de définition de la variable et peut être utilisée conjointement avec -show-origin :
$ git --list --show-scope --show-origin
fichier global :/home/user/.gitconfig diff.interhunkcontext=1
fichier global :/home/user/.gitconfig push.default=current
[…] fichier local :.git/config branch.master.remote=origin
fichier local :.git/config branch.master.merge=refs/heads/master$ git config --show-scope --get-regexp 'diff.*'
largeur globale diff.statgraph 35
local diff.colormoved plaine$ git config --global --unset diff.statgraphwidth
- Dans les paramètres de liaison L'utilisation de masques dans les URL est autorisée. Tous les paramètres HTTP et informations d'identification dans Git peuvent être définis à la fois pour toutes les connexions (http.extraHeader, credential.helper) et pour les connexions basées sur des URL (credential.https://example.com.helper, credential.https: //example. com.helper). Jusqu'à présent, les caractères génériques tels que *.example.com n'étaient autorisés que pour les paramètres HTTP, mais n'étaient pas pris en charge pour la liaison des informations d'identification. Dans Git 2.26, ces différences sont éliminées et, par exemple, pour lier un nom d'utilisateur à tous les sous-domaines, vous pouvez désormais spécifier :
[identifiant "https://*.example.com"]
nom d'utilisateur = taylorr
- L'expansion de la prise en charge expérimentale du clonage partiel (clones partiels) se poursuit, vous permettant de transférer seulement une partie des données et de travailler avec une copie incomplète du référentiel. La nouvelle version ajoute une nouvelle commande "git sparse-checkout add", qui vous permet d'ajouter des répertoires individuels pour appliquer l'opération "checkout" à une partie seulement de l'arborescence de travail, au lieu de lister tous ces répertoires à la fois via la commande "git". sparse-checkout set" (vous pouvez ajouter un répertoire un par un, sans re-spécifier la liste entière à chaque fois).
Par exemple, pour cloner un dépôt git/git sans valider des blobs, en limitant l'extraction au seul répertoire racine de la copie de travail et en marquant séparément l'extraction pour les répertoires « t » et « Documentation », vous pouvez spécifier :$ git clone --filter=blob:aucun --sparse [email protected]:git/git.git
$cdgit
$ git sparse-checkout init --cone$ git sparse-checkout ajouter t
....
$ git sparse-checkout ajouter Documentation
....
$ git liste de paiement clairsemée
Documentation
t - Les performances de la commande « git grep », utilisée pour rechercher à la fois le contenu actuel du référentiel et les révisions historiques, ont été considérablement améliorées. Pour accélérer la recherche, il était possible d'analyser le contenu de l'arborescence de travail à l'aide de plusieurs threads (« git grep –threads »), mais la recherche dans les révisions historiques était monothread. Désormais, cette limitation a été supprimée grâce à la mise en œuvre de la possibilité de paralléliser les opérations de lecture à partir du stockage d'objets. Par défaut, le nombre de threads est égal au nombre de cœurs de processeur, ce qui dans la plupart des cas ne nécessite plus de définir explicitement l'option « -threads ».
- Ajout de la prise en charge de la saisie semi-automatique des sous-commandes, chemins, liens et autres arguments de la commande « git worktree », qui vous permet de travailler avec plusieurs copies de travail du référentiel.
- Ajout de la prise en charge des couleurs vives comportant des séquences d'échappement ANSI. Par exemple, dans les paramètres des couleurs de surbrillance « git config –color » ou « git diff –color-moved », vous pouvez spécifier « %C(brightblue) » via l'option « --format » pour le bleu vif.
- Ajout d'une nouvelle version du script , assurant l'intégration avec le mécanisme pour accélérer le suivi des modifications de fichiers et l’apparition de nouveaux fichiers. Après la mise à jour, git est requis hook dans le référentiel.
- Ajout d'optimisations pour accélérer les clones partiels lors de l'utilisation de bitmaps
(machinerie bitmap) pour éviter une recherche complète de tous les objets lors du filtrage de la sortie. La vérification des blobs (—filter=blob:none et —filter=blob:limit=n) pendant le clonage partiel est désormais effectuée
nettement plus rapide. GitHub a annoncé des correctifs avec ces optimisations et une prise en charge expérimentale du clonage partiel. - La commande "git rebase" a été déplacée vers un autre backend, en utilisant le mécanisme de "fusion" par défaut (précédemment utilisé pour "rebase -i") au lieu de "patch+apply". Les backends diffèrent de quelques petites manières, par exemple, après avoir continué une opération après avoir résolu un conflit (git rebase --continue), le nouveau backend propose de modifier le message de validation, tandis que l'ancien utilisait simplement l'ancien message. Pour revenir à l'ancien comportement, vous pouvez utiliser l'option "--apply" ou définir la variable de configuration "rebase.backend" sur "apply".
- Un exemple de gestionnaire pour les paramètres d'authentification spécifiés via .netrc a été réduit à une forme adaptée à une utilisation prête à l'emploi.
- Ajout du paramètre gpg.minTrustLevel pour définir le niveau de confiance minimum pour divers éléments effectuant la vérification de la signature numérique.
- Ajout de l'option "--pathspec-from-file" à "git rm" et "git stash".
- L'amélioration des suites de tests s'est poursuivie en vue de la transition vers l'algorithme de hachage SHA-2 au lieu de SHA-1.
Source: opennet.ru