Git 2.56 ajoute history drop et delete-merged

Git 2.56 est en version candidate et est attendu pour la fin septembre 2026. LWN.net a rapporté que cette version porte plus de 700 commits hors fusion. La plupart relèvent de la plomberie. Mais une poignée de nouvelles commandes change ce qu'un développeur peut faire sans passer par un rebase interactif.

LWN qualifie la 2.56 de "solide version" et écrit que le projet "garde une grande partie de son travail le plus important pour plus tard". Ce plus tard, c'est Git 3.0.

Les nouvelles commandes

Commande ou option	Ce qu'elle fait
git history drop	Retire des commits désignés d'une branche en rejouant ceux qui suivent
git repo info	Affiche les chemins du dépôt, absolus et relatifs
git add --resolved	N'indexe que les chemins de fusion dont vous avez réglé les conflits
git branch --delete-merged	Supprime les branches locales déjà fusionnées dans leur branche de suivi distante
git bisect --reset-when-found	Restaure l'état initial dès que bisect trouve le commit
git replay --linearize	Supprime les commits de fusion en rejouant l'historique
git refs	Crée, supprime, met à jour et renomme directement des références

Ce que fait history drop, et où elle s'arrête

git history drop retire d'une branche un commit que vous désignez. Elle procède en rejouant chaque commit venu après lui. C'est le travail que l'on fait aujourd'hui avec un rebase interactif, tapé avec soin, ligne par ligne.

Une limite mérite d'être connue avant d'en dépendre. Les notes de version de Git indiquent que la commande refuse toujours de fonctionner si l'historique contient des commits de fusion. Beaucoup de branches réelles en contiennent. La commande convient donc à une branche de fonctionnalité linéaire plutôt qu'à une branche partagée de longue durée.

git replay --linearize aborde le même terrain par l'autre côté. Elle supprime les commits de fusion en rejouant, ce qui aplatit un historique emmêlé en une ligne droite.

De plus petits changements que vous remarquerez

git add --resolved vise un désordre fréquent en pleine fusion. Pendant un conflit, vous réparez souvent deux fichiers et laissez d'autres modifications dans la copie de travail. La nouvelle option n'indexe que les chemins dont vous avez réglé les conflits, et laisse vos autres changements locaux tranquilles.

git branch --delete-merged fait le ménage parmi les branches locales déjà fusionnées dans celle qu'elles suivent. Git affiche aussi un message plus clair quand l'une de ces branches sert à une bissection.

Les notes de version du projet Git listent plusieurs corrections plus discrètes. Git repère désormais les fautes de frappe dans des commandes comme git push origin/main. Un nouveau réglage fetch.followRemoteHEAD contrôle la façon dont un fetch traite la branche par défaut du dépôt distant. Demander l'aide d'une commande se termine maintenant par le code 0 au lieu de 129, ce qui empêche un script de lire une demande d'aide comme un échec. Les commandes de configuration réessaient en cas de collision, ce qui réduit les erreurs de verrou quand deux commandes écrivent en même temps.

En dessous, git cat-file --batch formate sa sortie plus vite, et git log --follow gère mieux qu'avant un historique non linéaire.

Ce que cela signifie pour les développeurs

Essayez git history drop sur une copie de branche avant de lui confier une vraie. La restriction sur les commits de fusion décide si la commande convient à votre façon de travailler. Lancez git log --merges sur la plage que vous voulez modifier : si cela affiche quoi que ce soit, la commande refusera.

git branch --delete-merged est celle à intégrer à vos habitudes. La plupart des développeurs accumulent des dizaines de branches locales périmées et les nettoient avec un enchaînement shell copié d'un billet de blog il y a des années. Une option intégrée est plus sûre, car elle vérifie la branche de suivi distante au lieu de comparer des noms.

Le changement de code de sortie mérite un coup d'œil à votre propre outillage. Tout script qui traitait 129 comme le signal d'une demande d'aide verra maintenant 0. C'est le comportement correct, mais c'est un changement de comportement, et il échouera en silence plutôt que bruyamment.

Rien ici ne casse un dépôt existant. Les changements qui le feront sont dans la version suivante : Git 3.0 fait passer les nouveaux dépôts à SHA-256 et reftable, et rend Rust obligatoire à la compilation. Le document de Git sur les ruptures ne donne toujours aucune date pour la 3.0. Voyez la 2.56 comme le dernier arrêt tranquille avant celle-là.