lancement d'un système de gestion décentralisé des textes sources . Git est l'un des systèmes de gestion de versions les plus populaires, fiables et performants, offrant des outils flexibles de développement non linéaire 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'ensemble de l'historique précédent est utilisé dans chaque commit, et il est également possible de vérifer numériquement par des signatures des développeurs pour des tags et commits spécifiques.
Comparé à la version précédente, la nouvelle version intègre 544 modifications, préparées par 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, permettant de passer rapidement d'un ensemble de paramètres à un autre sans se plonger dans les détails des options spécifiques. Grâce aux macros, il n'est pas nécessaire de mémoriser précisément quels paramètres changer pour activer une fonctionnalité donnée. Par exemple, en cas de ralentissement lors de l'utilisation d'un grand dépôt, il peut être nécessaire de passer à un nouveau mécanisme d'indexation, d'activer la compression des préfixes de chemins et d'utiliser le cache des fichiers non suivis en réglant le paramètre index.version à 4 et en activant core.untrackedCache. Les macros permettent d’économiser du temps en évitant de chercher la solution appropriée dans la documentation et d'activer immédiatement les réglages optimisés pour les dépôts contenant beaucoup de fichiers :
git config feature.manyFiles true
- La conservation des objets sous forme de graphe de commits (commit-graph) est activée par défaut, où l'indexation utilise une structure en graphe au lieu d'une liste linéaire de hachages d'objets avec des références à d'autres objets. Auparavant, pour identifier les versions contenant une correction spécifique, il était nécessaire de charger chaque objet depuis le disque à la recherche de références, tandis qu'avec le stockage sous forme de graphe, il est possible de déterminer immédiatement toutes les connexions nécessaires. La transition vers la conservation sous forme de graphe de commits dans les dépôts du noyau Linux et de Git a permis d'atteindre presque un doublement des performances des opérations sur les branches. Pour activer la nouvelle méthode de stockage après une mise à jour vers Git 2.24, il suffit d'exécuter la commande « git gc ».
Les modifications liées à commit-graph incluent la harmonisation de l'indicateur de progression de l'exécution des opérations dans les commandes liées à commit-graph (« git commit-graph write », « git commit-graph verify », etc.) pour qu'il soit conforme à d'autres commandes. L'indicateur de progression est désormais affiché par défaut uniquement pour le terminal (pour changer ce comportement, utilisez l'option « -[no-]progress »). De plus, un nouveau paramètre de configuration fetch.writeCommitGraph a été ajouté, permettant la mise à jour automatique du fichier de graphique de commits lors des opérations « git fetch » (tous les commits extraits de dépôts externes seront immédiatement inclus dans le commit-graph sans nécessiter d'exécution séparée de auto-gc);
- Une commande a été ajoutée pour réécrire l'historique des modifications — «», qui est une alternative plus simple à la commande «» pour exécuter des opérations sur l'historique des modifications dans le dépôt (par exemple, supprimer un fichier du dépôt ou extraire l'historique des modifications d'un certain répertoire). Pour améliorer l'efficacité, des opérations dans « git filter-repo » sont effectuées sur une vue historique sous forme de flux continu, plutôt que par un examen ordonné par commit.
La filtrage de l'historique se fait à l'aide de l'option « -path-{glob,regex} », permettant d'appliquer à la fois des motifs simples et des expressions régulières. Il existe également des options pour effectuer des opérations de « recherche et remplacement » ou pour nettoyer les objets binaires dépassant une certaine taille. Chaque commit réécrit reçoit un nouvel identifiant de hachage SHA-1 et, conformément à ce nouvel identifiant, toutes les références au commit remplacé sont mises à jour.
Pour afficher un résumé avec des statistiques sur le dépôt (nombre d'objets par type, les plus gros fichiers et répertoires, quelles extensions occupent le plus d'espace disque, etc.), une option « -analyze » est prévue. Pour étendre les fonctionnalités, il est possible de connecter des gestionnaires de rappel personnalisés en Python, permettant à la fois de créer de nouvelles sous-commandes et de gérer divers événements (par exemple, de nouveaux types de fichiers);
- Une nouvelle option « —end-of-options » a été ajoutée, permettant de séparer les options des noms de liens qui peuvent commencer par le caractère « - » et être interprétés comme des options (« git log —end-of-options —super-dangerous-option »). Bien qu'il soit possible d'échapper de tels noms dans l'usage courant comme « git log 'refs/heads/—super-dangerous-option' », des problèmes d'identification de l'espace de noms pouvaient survenir dans les scripts. Le séparateur classique « — » ne s'applique pas ici, 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/file »);
- Les options « —strategy » et « —strategy-option » ont été ajoutées à « git rebase —rebase-merges » pour sélectionner ;
- Un nouveau hook « .git/hooks/pre-merge-commit » a été ajouté, appelé après l'exécution d'une fusion, mais avant l'enregistrement du commit résultant;
- Le moteur d'autocomplétion des commandes a été conçu pour prendre en charge l'ajout de variables de configuration liées aux paramètres spécifiques 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 pour obtenir une suggestion.
De plus, les développeurs de Git un code de conduite pour les participants du projet, qui définit les principes fondamentaux pour résoudre les situations conflictuelles. Ce document est basé sur les recommandations du «», appliquées dans de nombreux projets open source, y compris le noyau Linux, Eclipse, Freedesktop, GitLab, Ruby et Kubernetes. Le document définit l'égalité des chances pour tous les participants, indépendamment de leur vision du monde, âge, sexe, croyances religieuses, niveau d'éducation, statut social et nationalité. La communauté encourage une forme de communication amicale, la compréhension et la sympathie pour les problèmes des autres participants, l'acceptation des critiques constructives et la prise des meilleures décisions pour la communauté entière. Le trolling, les manières de communication offensantes, les tentatives de dégradation, le harcèlement, les violations de la vie privée, la divulgation d'informations personnelles et d'autres actions considérées comme inappropriées lors de communications professionnelles ne sont pas tolérés.
Source : opennet.ru
