Skip to content
Tech AI Wire

Git 3.0 passera à SHA-256 par défaut et exigera Rust

Git 2.56-rc0 est sorti le 11 septembre 2026, et la version 3.0 qui suit fera passer les nouveaux dépôts à SHA-256, à reftable et à la branche main.

Par Tech AI Wire Team

3 min de lecture

XLinkedIn
The Git project's BreakingChanges documentation page on git-scm.com, open at the section describing backwards-incompatible releases.

En chiffres

SHA-1 collision attacks the hash change cites: 2015, 2017 and 2020
3
release candidate published on September 11, 2026
2.56

Git 2.56-rc0 a été publié le 11 septembre 2026, et c'est la version suivante qui casse des choses. Le document des changements incompatibles de Git énumère ce que la version 3.0 change pour les nouveaux dépôts. Ils utiliseront des empreintes SHA-256 au lieu de SHA-1, stockeront les références au format reftable et nommeront la première branche main. Compiler Git exigera en plus Rust. Phoronix a rapporté la version candidate et situe Git 3.0 vers la fin 2026.

Chacun de ces réglages ne s'applique qu'aux dépôts créés après le changement. Les dépôts existants continuent de fonctionner tels quels.

Les quatre réglages par défaut qui changent

RéglageAujourd'huiDans Git 3.0
Algorithme d'empreinteSHA-1SHA-256
Stockage des référencesfilesreftable
Nom de la première branchemastermain
safe.bareRepositoryallexplicit

Le changement d'empreinte repose sur un argument de sécurité. Le document de Git cite trois attaques contre SHA-1 par leur nom : SHAppening en 2015, SHAttered en 2017 et Shambles en 2020. Une collision d'empreintes dans un système de gestion de versions signifie que deux objets différents peuvent revendiquer la même identité.

Reftable remplace l'ancienne organisation où chaque référence était un fichier sur le disque. Le document de Git donne deux raisons : ce format se comporte correctement sur les systèmes de fichiers de Windows et macOS qui ignorent la casse, et il est plus rapide sur les dépôts comptant de nombreuses références.

Le passage de safe.bareRepository de all à explicit est un changement plus petit, mais avec une attaque réelle derrière lui. Le réglage actuel laisse Git découvrir un dépôt nu n'importe où dans une arborescence, y compris un dépôt qu'un attaquant a déposé dans une copie de travail.

Rust devient obligatoire

L'exigence de Rust arrive par étapes. Le document de Git décrit la séquence : la prise en charge de Rust a été détectée automatiquement dans Git 2.52, activée par défaut dans 2.55, et devient obligatoire dans 3.0.

Cela place Git aux côtés d'autres logiciels de base qui franchissent le même pas ; Ubuntu remplace les coreutils GNU par des implémentations en Rust dans sa prochaine version. Pour qui compile Git depuis les sources sur une plateforme inhabituelle, une chaîne d'outils Rust devient une condition à prévoir.

Git 3.0 retire aussi des fonctions dépréciées depuis des années, dont git pack-redundant, git whatchanged, la prise en charge des fichiers graft et d'anciens mécanismes de stockage des dépôts distants.

Ce que 2.56 apporte

Les notes de version de 2.56 portent surtout sur les performances et la plomberie. L'énumération des objets libres pendant git status passe d'une complexité quadratique à O(n log n). Le calcul de la base de fusion s'arrête plus tôt quand il le peut, ce que les notes décrivent comme des gains significatifs.

Il y a une nouvelle surface de commande : git refs gagne des sous-commandes pour créer, supprimer, mettre à jour et renommer des références. Le message de conseil de git status nomme désormais le dépôt distant et la branche dans le git pull qu'il propose quand votre branche et son amont ont divergé.

Phoronix note que 2.56 ajoute aussi des motifs de diff pour Swift, couvrant attributs, modificateurs, initialiseurs faillibles et génériques, et durcit le moteur de fusion ORT face aux arbres corrompus. En dessous, la version poursuit le retrait des variables globales au profit d'un état par dépôt, ce qui prépare des bases d'objets interchangeables.

Ce que cela signifie pour les développeurs

La question de compatibilité n'est pas de savoir si votre Git fonctionne, mais si votre forge suit. Un dépôt SHA-256 doit être compris par tout ce qui le touche, y compris votre hébergeur, vos exécuteurs d'intégration continue et tout outil qui analyse des identifiants d'objets. Testez ce chemin avant de créer un dépôt avec le nouveau réglage.

Vérifiez dans votre propre code les hypothèses figées sur la longueur des empreintes. Quarante caractères hexadécimaux sont inscrits depuis vingt ans dans des scripts, des expressions régulières et des colonnes de base de données. Les noms d'objets SHA-256 font soixante-quatre caractères, et un varchar(40) les tronquera simplement.

Reftable mérite une adoption précoce si vous portez des dépôts aux milliers de branches ou d'étiquettes, car c'est là que le format paie. Le nom de branche par défaut compte le moins : la plupart des équipes l'ont réglé il y a des années, et un dépôt créé après le changement se renomme en une commande.

Sources

  1. Git 2.56-rc0 Released With Updated Contribution Guidelines, Improvements For Swift - Phoronix
  2. Git 2.56 release notes - Git project
  3. Git BreakingChanges documentation - Git project

Articles liés