Git 2.56.0 accélère merge-base et réduit la taille des repacks

Git 2.56.0 est disponible. Junio C Hamano, qui maintient Git, a annoncé la sortie le 28 septembre 2026. L'essentiel des gains porte sur la vitesse et l'espace disque. Une requête merge-base sur le noyau Linux prend désormais 3 887 étapes au lieu de 167 441. Une nouvelle façon d'empaqueter les dépôts a réduit de 71 % un grand dépôt de test.

La version contient 748 commits hors fusion depuis la sortie de Git 2.55 en juin, selon l'annonce de Hamano. Ils proviennent de 104 développeurs, dont 39 contribuaient à Git pour la première fois.

Tech AI Wire a présenté en avant-première les nouvelles commandes de la version candidate la semaine dernière, dont git history drop et git branch --delete-merged. Cet article couvre ce que les notes de version finales, GitHub et GitLab ajoutent par-dessus.

Merge-base jusqu'à 70 fois plus rapide

Une base de fusion (merge base) est le commit le plus récent que deux branches ont en commun. Git la calcule chaque fois que vous fusionnez, faites un rebase ou demandez à quel point une branche s'est éloignée de main. Sur un grand dépôt, ce parcours en arrière dans l'historique peut être lent.

Git 2.56 arrête le parcours plus tôt. L'annonce de Hamano indique que Git s'arrête désormais « lorsque les commits exclusifs d'un côté dans la file d'attente sont épuisés ». En clair, dès que Git peut prouver qu'une branche n'a plus rien à offrir, il cesse de chercher.

Le billet de GitHub sur les nouveautés chiffre le changement. Une requête merge-base sur le noyau Linux est passée de 167 441 étapes, en 0,29 seconde, à 3 887 étapes, en 0,01 seconde. Sur deux grands monorepos, GitHub a mesuré une accélération de 70 fois sur l'un et une accélération moyenne de 20 fois sur l'autre.

Un changement connexe réutilise des réponses antérieures dans des commandes comme git branch --contains, qui liste les branches contenant un commit donné. Cela accélère les vérifications que Git effectue pour savoir si un commit peut en atteindre un autre.

Des dépôts plus petits avec les repacks path-walk

Git stocke l'historique dans des fichiers pack, qui sont des paquets compressés d'objets. Un repack réécrit ces paquets pour gagner de la place. L'option --path-walk rassemble les objets chemin de fichier par chemin de fichier avant de les compresser, de sorte que les versions d'un même fichier sont comparées entre elles.

Lors du test de GitHub sur le dépôt Fluent UI, le pack est passé de 558,5 Mo à 164,4 Mo. C'est environ 71 % de moins. Dans 2.56, les repacks path-walk fonctionnent aussi avec les bitmaps d'accessibilité (reachability bitmaps) et les îlots delta (delta islands). Les serveurs Git utilisent ces deux fonctions pour démarrer rapidement les clones et pour garder séparés les forks qui partagent un stockage.

Les clones partiels peuvent de nouveau se délester des gros fichiers

Un clone partiel télécharge l'historique sans tous les gros fichiers. Il récupère les blobs, le terme de Git pour le contenu des fichiers, uniquement quand une commande en a besoin. Avec le temps, ces fichiers récupérés s'accumulent sur le disque.

Git 2.56 ajoute un moyen de les supprimer. L'annonce de la version indique que git repack avec --drop-filtered supprime les blobs locaux au-delà d'une limite de taille que le serveur peut toujours fournir. Le billet de GitHub donne un exemple complet : git repack -a --filter=blob:limit=1m --drop-filtered. C'est une étape manuelle, pas un nettoyage automatique.

Des corrections de conflits plus sûres et des logs plus clairs

git add --resolved n'indexe que les fichiers dont vous avez corrigé les conflits de fusion. La version finale vérifie aussi que ces fichiers ne contiennent plus de marqueurs de conflit, les lignes <<<<<<< que Git écrit dans un fichier en conflit. Il devient ainsi plus difficile qu'un fichier à moitié corrigé se glisse dans un commit.

git log --follow suit désormais mieux un fichier à travers un historique comportant plusieurs renommages et fusions. git log --graph indente les commits racines, ceux qui n'ont pas de parent, pour que les historiques séparés ressortent. L'option --no-graph-indent ou le réglage log.graphIndent contrôle ce comportement.

Ce qui vient après 2.56

La prochaine version ne sera pas la 2.57. Karthik Nayak, ingénieur chez GitLab, écrit que Git prévoit de sauter à 2.98 en décembre 2026. Git 2.99 et Git 3.0 sont attendus au printemps 2027. « Ce saut important sert d'indication, aux mainteneurs en aval comme aux utilisateurs, qu'un grand changement arrive », écrit Nayak.

Ce changement, c'est le passage de Git 3.0 à SHA-256 et à reftable par défaut, ainsi que Rust comme élément obligatoire de la compilation.

Ce que cela signifie pour les développeurs

La plupart des développeurs obtiennent l'accélération de merge-base simplement en mettant à jour. Elle compte surtout dans les grands monorepos et dans les jobs de CI qui font des rebases ou comparent des branches de nombreuses fois par jour. Si votre pipeline fige une ancienne version de Git dans une image de conteneur, c'est ce verrou qui vous sépare du gain.

Essayez git add --resolved la prochaine fois qu'une fusion s'arrête sur des conflits. Cette option remplace l'habitude de lancer git add . en pleine fusion, qui indexe toutes les modifications égarées de l'arborescence en plus des corrections.

Si vous gérez un serveur Git ou conservez de grands miroirs, testez --path-walk sur une copie d'un dépôt et comparez les tailles de pack. Le résultat de Fluent UI provient d'un seul dépôt, et votre mélange de fichiers sera différent. Mesurez avant de modifier une tâche de repack en production.

Enfin, préparez-vous au saut de version. Un script qui compare la sortie de git --version et attend 2.57 ensuite rencontrera 2.98 à la place. Vérifiez ces comparaisons dès maintenant, tant que le changement est encore à plusieurs mois.