Git 2.56 accélère la recherche d’ancêtres jusqu’à 70 fois et fiabilise la résolution de conflits
La version 2.56 de Git ajoute git add --resolved, qui refuse d’indexer un fichier encore porteur de marqueurs de conflit, et optimise le calcul des merge bases, jusqu’à 70 fois plus rapide sur les monorepos. Mettez à jour votre outillage et évaluez le repack path-walk si vous hébergez de gros dépôts.
28 septembre 2026. Git publie sa version 2.56, détaillée le jour même par Elijah Newren, staff software engineer chez GitHub et concepteur de merge-ort, dans la série « Highlights from Git ». Septembre 2026. Les deux changements de tête ne sont pas des fonctions spectaculaires, mais deux correctifs de fond : une commande qui refuse d’indexer un conflit mal résolu, et un calcul d’ancêtres communs jusqu’à 70 fois plus rapide sur les monorepos. 29 septembre 2026. Le repack path-walk devient enfin compatible avec les bitmaps et les delta islands. Pourquoi c’est important : cette version fiabilise et accélère les deux gestes que chaque développeur répète des dizaines de fois par jour — fusionner et fouiller l’historique.
git add —resolved : ne plus indexer un conflit mal résolu
Résoudre un conflit de fusion se décompose en deux temps. On édite d’abord le fichier jusqu’à obtenir le résultat voulu, puis on l’indexe pour signaler à Git que le conflit est clos. La seconde étape paraît triviale, mais les commandes existantes facilitent l’erreur : git add -u met à jour tous les chemins modifiés suivis, y compris des modifications locales sans rapport avec le conflit, et peut même indexer un fichier qui contient encore des marqueurs de conflit.
Git 2.56 introduit un mode pensé pour cette étape précise :
$ git add --resolved
fatal: the following paths still have conflict markers:
recipe.txt
$ # Éditez recipe.txt et retirez les marqueurs de conflit.
$ git add --resolved
$ git status --short
M notes.txt
M recipe.txtgit add --resolved ne considère que les chemins encore non fusionnés dans l’index. Avant d’indexer quoi que ce soit, il scanne les fichiers réguliers non fusionnés à la recherche de marqueurs de conflit résiduels. S’il en trouve un, il signale les chemins concernés et laisse l’index inchangé. Le contrôle est tout-ou-rien : dans la sélection, si un seul fichier porte encore un marqueur, Git n’indexe rien. Les suppressions résolues et les conflits binaires, dépourvus de marqueurs textuels, sont en revanche indexés normalement.
La commande accepte un pathspec pour restreindre les chemins examinés, mais la vérification tout-ou-rien s’applique toujours à l’intérieur de cette sélection. Elle est volontairement plus étroite que git add -u ou git add -A, avec lesquels elle ne peut pas être combinée, et elle ignore les fichiers suivis qui n’ont jamais été en conflit. C’est un garde-fou taillé pour les mainteneurs dont une fusion démarre souvent avec des modifications locales déjà présentes.
Un calcul d’ancêtres communs qui s’arrête plus tôt
De nombreuses opérations de Git doivent trouver le meilleur ancêtre commun de deux commits. Les fusions s’en servent comme point de départ pour combiner les changements, et les diffs à trois points l’utilisent pour situer le début du travail d’une branche. Les forges effectuent le même calcul pour les diffs de pull request, les vérifications de fusion et les plages de revue.
Git trouve ces ancêtres en remontant l’historique depuis les deux extrémités. Imaginez que les commits accessibles d’un côté soient peints en bleu et ceux de l’autre en rouge : un commit atteint par les deux couleurs est un candidat merge-base. Trouver un seul candidat ne suffit pas toujours — les fusions « criss-cross » produisent plusieurs merge bases dont aucune n’est l’ancêtre d’une autre, et Git doit continuer à marcher jusqu’à être certain de les avoir toutes. Mais l’ancienne règle d’arrêt pouvait continuer à traiter une longue traîne d’historique déjà commun, alors même qu’un autre merge base était devenu impossible.
Git 2.56 compte combien de commits en attente restent peints exclusivement par chaque côté. Une fois qu’un côté exclusif est épuisé, plus aucun point de rencontre ne peut apparaître, et Git peut s’arrêter tout en retournant chaque merge base. La différence est spectaculaire quand d’anciennes branches ont été fusionnées dans un historique bien plus long : dans un cas réel de monorepo, le parcours est passé de 0,68 seconde à 0,01 seconde. Les évaluations en production sur deux grands monorepos montrent de nombreux cas environ 70 fois plus rapides dans l’un, et une amélioration moyenne d’environ 20 fois dans l’autre.
La série corrige aussi un cas de performance historique du noyau Linux. Avec le commit-graph v2 par défaut, la commande git merge-base --all v4.8 v4.9 passe de 167 441 étapes de parcours et 0,29 seconde à 3 887 étapes et 0,01 seconde.
L’effet ne se limite pas à la ligne de commande. Les forges exécutent ce même calcul à chaque affichage du diff d’une pull request, à chaque vérification de fusion et à chaque plage de revue. Un gain de 20 à 70 fois sur ce chemin se propage donc à toute l’expérience de revue : c’est la latence entre le clic sur une pull request et l’affichage de son diff qui se contracte, et la facture CPU de l’hébergement qui baisse d’autant.
path-walk : des packs 71 % plus petits, désormais compatibles serveur
Quand Git repacke un dépôt, il cherche des objets similaires à stocker efficacement sous forme de deltas. La recherche traditionnelle regroupe les candidats à l’aide d’un hash de nom. Le repack path-walk visite au contraire les objets par leur emplacement dans l’arborescence, rapprochant les versions d’un même chemin et découvrant souvent de bien meilleures relations de delta.
Les économies de stockage sont substantielles. Dans un benchmark utilisant un clone récent du dépôt Fluent UI et forçant Git à recalculer les deltas, un repack bitmappé classique a produit un pack de 558,5 Mo, tandis que le repack --path-walk produisait un pack de 164,4 Mo, soit environ 71 % plus petit.
Mais les hébergeurs de dépôts ont besoin de plus que de petits packs. Ils utilisent couramment des bitmaps de reachability pour répondre vite aux requêtes d’énumération d’objets, et certains utilisent des delta islands pour empêcher les objets d’un groupe de références de dépendre d’objets disponibles seulement dans un autre. Le repack path-walk était incompatible avec les deux, ce qui limitait son déploiement. Git 2.56 lève ces deux restrictions : un repack path-walk peut désormais sélectionner les commits d’un nouveau bitmap, et il effectue la comptabilité exigée par les delta islands. Les hébergeurs peuvent donc évaluer les économies sans renoncer au service bitmap ni à l’isolation.
Le reste de l’iceberg
D’autres nouveautés valent le détour. La commande expérimentale git history continue de grandir : après reword et split en 2.54, puis fixup en 2.55, la 2.56 ajoute git history drop <commit>, qui supprime un commit et rejoue ses descendants sur son parent, en préservant les modifications locales non liées.
Git 2.56 poursuit aussi la consolidation des commandes de bas niveau de gestion des références sous la boîte à outils git refs :
git refs create refs/heads/topic <nouvelle-valeur>
git refs update refs/heads/topic <nouvelle-valeur> [<ancienne-valeur>]
git refs delete refs/heads/topic [<ancienne-valeur>]
git refs rename refs/heads/old refs/heads/newLes anciennes valeurs optionnelles fournissent une protection de type compare-and-swap pour les mises à jour et les suppressions. Ce sont des commandes volontairement bas niveau — git refs rename déplace la référence et son reflog sans effectuer les ajustements de configuration de branche que ferait git branch -m.
Verdict
Si vous fusionnez régulièrement des branches avec des modifications locales en cours, adoptez git add --resolved dès la mise à jour — c’est le correctif le plus immédiatement utile, et il élimine une classe entière d’erreurs silencieuses où l’on indexe un conflit mal résolu ou un fichier étranger à la fusion. Si vos opérations merge-base ou log sont lentes sur un gros monorepo, la mise à jour vers 2.56 est prioritaire : un gain de 20 à 70 fois sur le calcul des ancêtres se ressent à chaque git pull comme à chaque chargement de page de forge. Et si vous hébergez de grands dépôts, déployez 2.56 et évaluez --path-walk sur des copies de test : avec des packs jusqu’à 71 % plus petits et la compatibilité bitmap et delta islands enfin acquise, le retour sur investissement en stockage est mesurable avant toute migration des utilisateurs.