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 544 modifications préparées avec la participation de 78 développeurs, dont 21 ont participé au développement pour la première fois. :
- Ajout de la prise en charge des macros de configuration, grâce auxquelles vous pouvez basculer rapidement entre différents ensembles de paramètres sans entrer dans les détails des options spécifiques qui leur sont associées. A l'aide de macros, il n'est pas nécessaire de se rappeler quels paramètres doivent être modifiés pour activer telle ou telle fonctionnalité. Par exemple, si un référentiel volumineux est lent, vous souhaiterez peut-être passer à un nouveau moteur d'indexation, activer la compression des préfixes de chemin et activer le cache de fichiers non suivis en définissant index.version sur 4 et en activant core.untrackedCache. Les macros permettent de ne pas perdre de temps à chercher la bonne solution dans la documentation, mais d'activer immédiatement des paramètres avec des optimisations pour les référentiels comportant un grand nombre de fichiers :
git config feature.manyFiles vrai
- Activé par défaut est le stockage d'objets sous la forme d'un graphe de validation (commit-graph), dans lequel ce n'est pas une liste linéaire de hachages d'objets avec des liens vers d'autres objets, mais une structure sous forme de graphe qui est utilisée pour l'indexation. . Si auparavant, afin de déterminer les versions contenant un certain correctif, il était nécessaire de charger chaque objet à partir du disque pour rechercher des liens, alors une fois stocké sous forme de graphique, vous pouvez immédiatement déterminer tous les liens nécessaires. Le passage au stockage sous forme de commit graph dans le noyau Linux et les référentiels Git nous a permis de multiplier presque par deux les performances des opérations avec les branches. Pour activer la nouvelle méthode de stockage après la mise à niveau vers Git 2.24, vous devez exécuter la commande « git gc ».
Parmi les changements associés à commit-graph, on note également que l'implémentation de l'indicateur de progression de l'opération dans les commandes liées à commit-graph (« git commit-graph write », « git commit-graph verify », etc.) a été apportée. à une forme commune avec d'autres commandes. .). L'indicateur de progression n'est désormais affiché que pour le terminal par défaut (utilisez l'option "-[no-]progress" pour modifier le comportement). De plus, un nouveau paramètre de configuration fetch.writeCommitGraph a été ajouté, qui permet la mise à jour automatique du fichier avec le commit-graph lors des opérations « git fetch » (tous les commits récupérés depuis des référentiels externes iront immédiatement vers le commit-graph sans qu'il soit nécessaire de le faire). exécutez auto-gc séparément);
- Ajout d'une commande pour écraser l'historique des modifications - "", qui est une alternative plus simple à la commande "» pour effectuer des opérations sur l'historique des modifications dans le référentiel (par exemple, supprimer un fichier du référentiel ou récupérer l'historique des modifications dans un répertoire spécifique). Pour améliorer l'efficacité, au lieu d'une analyse ordonnée validation par validation, git filter-repo effectue des opérations sur la représentation de l'historique sous la forme d'un flux continu.
Le filtrage de l'historique s'effectue à l'aide de l'option « -path-{glob,regex} », qui permet d'utiliser à la fois des masques simples et des expressions régulières. Il existe également des options pour effectuer une recherche et remplacer ou nettoyer les objets binaires dont la taille dépasse une taille spécifiée. Chaque validation réécrite est fournie avec un nouvel identifiant de hachage SHA-1 et toutes les références à la validation remplacée sont mises à jour conformément au nouvel identifiant.
Pour afficher un résumé des statistiques sur le référentiel (nombre d'objets par type, fichiers et répertoires les plus volumineux, quelles extensions nécessitent plus d'espace disque, etc.), l'option « -analyser » est fournie. Pour étendre les fonctionnalités, il est possible de connecter des gestionnaires de rappel arbitraires en Python, grâce auxquels vous pouvez à la fois créer de nouvelles sous-commandes et traiter divers événements (par exemple, de nouveaux types de fichiers) ;
- Ajout de l'option "--end-of-options" pour séparer les options des noms de liens, qui peuvent commencer par un caractère "-" et être traités comme des options ("git log --end-of-options -super-dangerous-option" ). Si dans la vie de tous les jours, de tels noms peuvent être échappés sous la forme « git log 'refs/heads/—super-dangerous-option' », alors les scripts pourraient avoir des problèmes pour définir l'espace de noms. Le délimiteur généralement accepté " - " n'est pas applicable dans ce cas, car il est déjà utilisé pour séparer les noms de liens des fichiers (par exemple, « git log —end-of-options —super-dangerous-option ^master — path/to /déposer");
- Ajout des options "--strategy" et "--strategy-option" à "git rebase --rebase-merges" pour sélectionner ;
- Ajout d'un nouveau gestionnaire ".git/hooks/pre-merge-commit" qui est appelé après la fin d'une fusion mais avant l'écriture de la validation résultante ;
- La prise en charge de la complétion des variables de configuration en relation avec les paramètres de commandes spécifiques a été ajoutée au moteur de complétion des commandes.
Par exemple, si vous devez taper « git -c core.autocrlf=false add path/to/my/file » mais que vous ne vous souvenez pas du nom exact de la variable « core.autocrlf », vous pouvez appuyer sur Tab et obtenir un indice.
De plus, les développeurs Git code de conduite pour un participant au projet, qui définit les principes de base pour résoudre les situations de conflit. Le document s'appuie sur les recommandations "", utilisé dans de nombreux projets open source, notamment le noyau Linux, Eclipse, Freedesktop, GitLab, Ruby et Kubernetes. Le document définit l'égalité des chances pour tous les participants, quels que soient leur vision du monde, leur âge, leur sexe, leurs préférences religieuses, leur niveau d'éducation, leur statut social et leur nationalité. La communauté accueille favorablement une forme de communication amicale, de compréhension, d'empathie pour les problèmes des autres participants, l'acceptation des critiques constructives et la prise des meilleures décisions pour l'ensemble de la communauté. Le trolling, les communications offensantes, les tentatives d'humiliation, le harcèlement, les violations de la vie privée, la divulgation d'informations personnelles et d'autres actions pouvant être considérées comme inappropriées pour la communication professionnelle ne sont pas autorisés.
Source: opennet.ru