Il y a quelques jours , la sortie de la nouvelle version de Git 2.3 a été annoncée . Git est l'un des systèmes de contrôle de version les plus populaires, fiables et performants, qui fournit des outils de développement non linéaires et flexibles basés sur la création de branches et la fusion.
Par rapport à la version précédente, 679 modifications ont été adoptées dans la nouvelle version, préparée avec la participation de 85 développeurs , dont 23 ont participé au développement pour la première fois.
Points forts de Git 2.31
Cette nouvelle version de Git 2.31 introduit la commande « git maintenance » , qui permet d'effectuer une maintenance périodique sur les systèmes ne prenant pas en charge cron . Par exemple, grâce à cette commande, vous pouvez programmer le processus de création de paquets du dépôt pour qu'il démarre périodiquement, évitant ainsi d'avoir à attendre la fin du verrouillage du dépôt lorsque la création des paquets est effectuée automatiquement après l'exécution de plusieurs commandes.
Autre changement notable : la prise en charge de la gestion d’un index inversé sur disque (revindex) pour les fichiers de paquets. Git stocke toutes les données sous forme d’objets, chacun dans un fichier distinct. Afin d’optimiser la gestion du dépôt, ces objets sont organisés en fichiers de paquets, où l’information est présentée comme un flux d’objets qui se succèdent.
Pour chaque archive de paquet, un fichier d'index (.idx) est créé, permettant d'utiliser l'identifiant de l'objet pour déterminer rapidement son emplacement au sein de l'archive. L'index inverse (.rev), proposé dans Git 2.31, vise à optimiser la détermination de l'identifiant d'un objet à partir de son emplacement dans l'archive.
Auparavant, cette conversion était effectuée à la volée lors de l'analyse d'un fichier de paquetage et stockée uniquement en mémoire, ce qui ne permettait pas la réutilisation de ces index et nécessitait leur génération à chaque fois. La construction d'un index se résume désormais à la création d'un tableau de paires position-objet et à leur tri par position, une opération qui peut s'avérer très longue pour les fichiers de paquetage volumineux.
De plus, nous constatons que des optimisations de performances basées sur l'apparence du format de fichier du graphe de commit ont été ajoutées , utilisées pour optimiser l'accès aux informations sur les commits, ainsi que de nouvelles données sur le nombre de commits générés, qui peuvent être utilisées pour accélérer les opérations supplémentaires sur les commits.
De plus, la possibilité de modifier le nom de branche par défaut dans les nouveaux dépôts (paramètre `init.defaultBranch`) a été ajoutée. Lors de l'accès à des dépôts externes, Git tente de vérifier la branche pointée par `HEAD` ; autrement dit, si le serveur externe utilise la branche « main » par défaut, l'opération `git clone` tentera de trouver la branche « main » en local.
Parmi les autres changements notables, citons :
- L'option "–disk-use" ajouté à la commande "git rev-list" pour afficher un résumé de la taille des objets.
- La prise en charge de la bibliothèque d'expressions régulières obsolète PCRE1 a été supprimée.
- Fourni la possibilité d'interdire de force l'utilisation de raccourcis, agissant indépendamment de l'algorithme de hachage. L'interdiction est activée en affectant la valeur "no" au paramètre core.abbrev.
- L'option "–path-format" a été ajoutée à la commande "git rev-parse" pour définir explicitement la sortie des chemins relatifs ou absolus.
- Les scripts de saisie semi-automatique de Bash facilitent l'ajout de règles d'achèvement pour les sous-commandes "git" personnalisées.
- Ajout de l'option "–stdin" à la commande "git bundle" pour lire les liens depuis le flux d'entrée standard.
- Les options «–left-only» et «–right-only» ont été ajoutées à la commande «git range-diff» pour n'afficher qu'un seul côté de la plage comparée.
- Ajout de l'option "–skip-to = "À la commande" git difftool "pour reprendre une session interrompue à partir d'un chemin arbitraire.
- Le code de conduite (code de conduite), qui définit les principes de base pour la résolution des conflits entre développeurs, a été mis à jour à la version 2.0 (auparavant la version 1.4 était utilisée).
Enfin, si vous souhaitez en savoir plus , vous pouvez consulter le lien suivant.