Quoi de neuf dans Git 2.34 et 2.35 ?

Par Maxime Bréhin • Publié le 10 février 2022 • 3 min

Tu préféres une vidéo ?

Tu as la flemme de lire, pas de soucis, je t’ai préparé un résumé en vidéo :

Git 2.34

Je commence par la version la plus ancienne, mais surtout celle qui apporte le plus de nouveautés !

Auto-correction interactive des commandes

Là je suis fan 🤩 ! Comme moi, tu souffres peut-être du « syndrome des moufles »™ quand tu tapes dans le terminal : tu manques des touches et saisis de travers tes commandes (« git pish » ou le célèbre « git vommit » 🤮).

Depuis un petit moment Git nous conseille la bonne commande via un petit texte juste après notre échec, et pouvait même l’exécuter automatiquement, si tu avais opté pour ce comportement. Mais Git 2.34 va plus loin et nous permet d’activer le prompt interactif :

git config --global help.autoCorrect prompt

Nouvelle stratégie de fusion par défaut

La stratégie de fusion par défaut a été changée de « recursive » à « ort », youhou 🙌 !! Bon OK, comme ça, il y a peu de chances que ça te parle. La stratégie ORT (pour “Ostensibly Recursive’s Twin”), comme son nom l’indique, est la stratégie jumelle de Recursive. « À quoi bon remplacer une stratégie par une autre identique ? » me diras-tu. Eh bien, pour deux raisons majeures :

• Recursive était devenue quasi impossible à maintenir en raison de son code légataire ;
• les performances méritaient d’être améliorées (les heuristiques restent inchangées, c’est l’implémentation et donc l’exécution qui posaient problème).

Pour te donner une idée des gains de performance, cette stratégie est :

• jusqu’à 500 fois plus rapide pour une fusion contenant des renommages ;
• jusqu’à 9 000 fois (tu as bien lu) plus rapide pour une série de fusions similaires, comme dans un rebase par exemple (grâce à la mise en cache et la réutilisation des résultats de fusions précédentes).

Surlignage du log en mode --grep

Ça a toujours manqué dans Git : le surlignage des termes recherchés dans les messages de commit via l’option --grep est enfin arrivé !

# `demo` est le terme recherché
git log --grep=demo

🪦 RIP --preserve-merges

Après des années de bons et loyaux services, l’option --preserve-merges dépréciée de la commande rebase a définitivement été retirée de Git. Ne sois pas triste 😿, sa remplaçante est là depuis un moment 😹 : --rebase-merges. L’intention finale reste la même puisqu’on reproduit nos fusions locales lors du rebase. Si te ne comprends pas ce que je raconte, tu peux regarder du côté de notre article « Bien utiliser Git merge et rebase ».

Signer avec des clés SSH

Peut-être as-tu déjà travaillé avec des projets dont les contenus (commits/tags) étaient certifiés par signature numérique, via des clés GnuPG. Cette signature est désormais possible avec des clés SSH (seulement à partir d’OpenSSH 8.8).

Voici une idée de ce que donnent des commits signés dans GitHub :

En vrac

Comme toujours on bénéficie de différentes optis, principalement concernant la performance, mais aussi concernant les submodules, la doc’…

Côté perf’, on bénéficie d’une amélioration du sparse-checkout, très utile pour optimiser le travail avec les mono-repo massifs (datant de Git 2.25).

La commande rebase nous donne une information plus claire lorsqu’elle ne rejoue pas certains commits dont le contenu est déjà présent (skip).

Si tu es curieux·se, tu peux aller creuser les release notes.

Git 2.35

Une seule nouveauté a retenu mon attention dans cette version : la possibilité de mettre de côté dans le stash uniquement ce qu’on a stagé (ce qu’on a préparé pour notre prochain commit avec un git add).

git stash --stage

Là aussi tu peux regarder les release notes.