- Git, utilisé par les développeurs du monde entier, engage des changements structurels en vue de la prochaine décennie, avec d’importantes refontes centrées sur la sécurité, l’évolutivité et l’ergonomie
- Le changement le plus visible est le passage de SHA-1 à SHA-256 : l’usage de SHA-1 devrait être interdit d’ici 2030, mais l’adoption avance lentement faute de support suffisant dans l’écosystème
- Avec l’adoption de Reftable, Git cherche à gérer efficacement des millions de références et à résoudre les contraintes du système de fichiers ainsi que les problèmes de concurrence
- Pour améliorer la gestion des fichiers volumineux, Large-object promisors et une base de données d’objets enfichable sont en cours de développement, avec une intégration progressive à partir de Git 2.50
- Sous l’influence de systèmes de gestion de versions émergents comme Jujutsu, Git veut prendre en charge des workflows modernes via une UI simplifiée et l’ajout de nouvelles commandes
Pourquoi Git doit évoluer
- Depuis sa sortie en 2005, Git s’est imposé pendant 20 ans comme un outil central, dont dépendent des millions de dépôts et d’innombrables scripts
- Mais les évolutions de l’environnement, comme les failles de sécurité de SHA-1, la hausse des très gros dépôts et la généralisation des pipelines CI, ont mis en évidence ses limites structurelles
- La possibilité de collisions de SHA-1 a été démontrée en 2017 par l’attaque SHAttered de CWI et Google
- Avec l’augmentation de la puissance de calcul des GPU, on atteint désormais un niveau où de grandes organisations peuvent calculer des collisions de hachage
- Plutôt qu’une refonte révolutionnaire, Git doit choisir une évolution progressive, en menant ces changements sans rompre la compatibilité avec l’écosystème existant
Transition vers SHA-256
- La prise en charge de SHA-256 a été ajoutée dans Git 2.29 (octobre 2020), mais les grandes plateformes comme GitHub ne la prennent toujours pas en charge
- Git, Dulwich et Forgejo offrent un support complet, tandis que GitLab, go-git et libgit2 en sont au stade du support expérimental
- SHA-1 est utilisé pour de simples vérifications d’intégrité, mais tout l’écosystème — signatures, CI, scripts — fonctionne en partant du principe d’une résistance aux collisions
- Les réglementations publiques et les exigences des entreprises imposent la suppression de SHA-1 d’ici 2030, et SHA-256 devrait devenir la valeur par défaut dans Git 3.0
- Pour accompagner la transition de l’écosystème, les utilisateurs sont encouragés à tester leurs outils et à demander le support à leur forge
Adoption de Reftable
- Git utilise aujourd’hui une structure de références lâches où chaque référence est stockée dans un fichier distinct
- Cela devient inefficace dans les dépôts comptant des dizaines de millions de références, et entraîne des problèmes liés à la sensibilité à la casse du système de fichiers ainsi que des incohérences de concurrence
- Reftable repose sur une structure de table au format binaire, qui permet des mises à jour atomiques et une gestion efficace des références
- Dans le cas d’un dépôt GitLab contenant 20 millions de références, le fichier packed-refs existant nécessite la réécriture de 2 Go
- Dans Git 3.0, Reftable deviendra le backend par défaut, et il est recommandé d’utiliser les commandes Git plutôt qu’un accès direct aux fichiers
Amélioration de la gestion des fichiers volumineux
- Git est efficace pour compresser les fichiers texte, mais devient inefficace avec les modifications de fichiers binaires, car l’objet entier doit être régénéré
- D’après l’analyse de GitLab, 75 % de l’espace des dépôts est occupé par des fichiers binaires de plus de 1 Mo
- La fonctionnalité Large-object promisors permet de stocker les gros objets dans un dépôt distant séparé afin de les transférer via un CDN ou une API S3
- L’implémentation du protocole a été achevée dans Git 2.50 à 2.52, et l’utilisation côté client est désormais possible
- La base de données d’objets enfichable introduira un format de stockage dédié aux binaires, avec prise en charge du stockage incrémental
- Git 2.53 a introduit une interface unifiée de base de données d’objets, et une preuve de concept (PoC) est attendue dans Git 2.54
Améliorations de l’interface utilisateur
- Les commandes Git sont critiquées de longue date pour leur complexité et leur manque de cohérence, tandis que Jujutsu (JJ), basé sur Rust, émerge comme alternative
- Jujutsu propose le repositionnement automatique de l’historique, le traitement des conflits comme des données et une approche où les commits sont manipulés comme des brouillons
- Sans casser les workflows existants, Git intègre progressivement certains avantages de Jujutsu
- Git 2.54 devrait ajouter les commandes
git history split et git history reword
- Davantage de sous-commandes d’édition de l’historique sont prévues à l’avenir
- Steinhardt souligne que Git apprend au contact de la concurrence, et que la modernisation de l’UI et l’amélioration de l’ergonomie sont en cours
Aucun commentaire pour le moment.