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 583 modifications préparées avec la participation de 84 développeurs, dont 32 ont participé au développement pour la première fois. :
- La possibilité de clonage partiel est proche de la stabilisation et de la pleine préparation, vous permettant de transférer seulement une partie des données et de travailler avec une copie incomplète du référentiel. Un clone typique copie toutes les données du référentiel, y compris chaque version de chaque fichier de l'historique des modifications. Pour les très grands référentiels, la copie de données entraîne une augmentation significative du trafic et de l'espace disque, même si le développeur n'est intéressé que par un sous-ensemble de fichiers. Pour faciliter la récupération d'une partie seulement de l'arborescence des sources de travail, la nouvelle version introduit une commande expérimentale "sparse-checkout" et une nouvelle option "--sparse" pour la commande "clone".
Auparavant, le processus de clonage sélectif était effectué via la tâche pour filtrer le contenu inutile et l'option « -no-checkout » pour désactiver le remplissage des fichiers manquants. Après cela, avant d'effectuer l'opération d'extraction, il était nécessaire d'activer le paramètre core.sparseCheckout et de définir une liste de modèles de chemin exclus dans le fichier .git/info/sparse-checkout. Par exemple, pour cloner sans blobs et empêcher l'extraction de fichiers de sous-répertoires de profondeur 2 ou plus, vous pouvez exécuter :
git clone --filter=blob:none --no-checkout /votre/repository/here repo
Dépôt de cd en $
$ cat >.git/info/sparse-checkout <EOF
/*
!/*
EOF
$ git config core.sparseCheckout 1
$ git paiement .La nouvelle commande « git sparse-checkout » simplifie grandement le travail et réduit le processus d'organisation du travail avec un référentiel incomplet aux commandes suivantes :
git clone --filter=blob:none --sparse /votre/repository/here repo
git sparse-checkout set /chemin/vers/check/outLa commande sparse-checkout vous permet de définir une liste de chemins pour l'extraction (set) sans configurer manuellement .git/info/sparse-checkout, ainsi que d'afficher la liste actuelle des chemins (liste) et d'activer ou de désactiver les extractions partielles (activer /désactiver).
Pour optimiser le travail avec de très grands référentiels et listes de modèles, le "", qui limite les modèles autorisés (au lieu des modèles arbitraires .gitignore, vous pouvez spécifier si tous les chemins et tous les fichiers d'un sous-répertoire donné doivent être extraits). Par exemple, si un grand référentiel a un répertoire « A/B/C » et que tout le travail est concentré dans le sous-répertoire « C », alors lorsque vous activez le mode sparseCheckoutCone, la commande « git sparse-checkout set A/B/ C » extraira tout le contenu de « C », mais de « A » et « B » il extraira uniquement les parties nécessaires pour travailler avec « C ».
- De la documentation ("git rebase -h"), toutes les références à l'option "--preserve-merges" ont été supprimées, qui est obsolète et devrait être utilisée à la place pour migrer un ensemble de commits.«.
- Pour améliorer la lisibilité des messages avec des correctifs envoyés aux listes de diffusion, l'option « git format-patch —cover-from-description subject » a été ajoutée, lorsqu'elle est spécifiée, le premier paragraphe du texte de description de la branche est utilisé comme sujet du lettre de motivation pour un ensemble de correctifs.
- Prise en charge implémentée de l'utilisation combinée de la commande « git apply -3way » et du paramètre « merge.conflictStyle » (« git apply » prend désormais en compte le style de description du conflit de merge.conflictStyle lorsqu'il est nécessaire de résoudre le conflit après avoir tenté pour appliquer un fichier de correctif au référentiel).
- Le code de définition de fonction utilisé dans des opérations telles que "git diff/grep --show-function/-function-context" a été étendu pour prendre en charge la définition des limites des fonctions dans les programmes de langage. .
- Une nouvelle option a été ajoutée à "git add", "git commit", "git reset" et d'autres commandes - "-pathspec-from-file", qui permet de charger une liste de chemins à partir d'un fichier ou d'un flux d'entrée , au lieu de les lister sur la ligne de commande.
- Le problème de détection des renommages au niveau du répertoire lors de l'écriture de commits a été résolu. La définition ne fonctionnait pas si le contenu d'un sous-répertoire était déplacé vers la racine du référentiel.
- Une première implémentation de la commande repensée « git add -i » a été proposée, vous permettant d'ajouter du contenu modifié de manière interactive, réécrit de Perl en C. Une refonte similaire de la commande « git add -p » est en cours.
- La commande « git log –graph » a été refactorisée, générant une image ASCII d'un graphique avec l'historique des modifications dans le référentiel. La refonte a permis d'améliorer et de simplifier considérablement le résultat sans déformer la structure de l'histoire, ce qui, par exemple, a résolu le problème de l'image dépassant la largeur de la ligne terminale.
- L'option "git log --format=.." permet de changer le format de sortie,
étendu avec la prise en charge des drapeaux « l/L » pour afficher uniquement la partie de l'adresse e-mail indiquée avant le symbole « @ » (par exemple, utile lorsque tous les développeurs ont tous les e-mails dans le même domaine). - Ajout d'une sous-commande « set-url » à la commande « git submodule ».
- Les kits de test ont été mis à jour en vue de la transition vers
algorithme de hachage SHA-2 au lieu de SHA-1.
Source: opennet.ru