Diagnostiquer avec Git

Un historique n'est pas qu'une archive : c'est le seul endroit qui garde la trace de pourquoi le code est ce qu'il est. Encore faut-il savoir l'interroger.

bisect : la dichotomie automatisée

« Ça marchait il y a trois semaines. » Entre-temps, quatre cents commits.

git bisect start
git bisect bad                    # l'état actuel est cassé
git bisect good v1.2.0            # cette version allait
# Git extrait le commit du milieu, tu testes, tu réponds
git bisect good     # ou bad

Chaque réponse divise l'espace de recherche par deux : quatre cents commits sont départagés en neuf essais. Et si le test est scriptable, tout se fait sans toi :

git bisect run ./verifier.sh      # code 0 = bon, autre = mauvais

C'est là que la stratégie d'intégration se paye. Avec des commits qui font une chose, bisect désigne une cause. Avec des écrasements de trois jours de travail, il désigne un gros paquet — et l'enquête recommence à l'intérieur.

Retrouver l'origine d'une ligne

git blame -L 42,48 src/lib/quiz.ts     # qui a écrit ces lignes, et dans quel commit
git log -S "SAFE_SLUG" --oneline       # les commits qui ajoutent ou retirent cette chaîne
git log --follow src/lib/lab.ts        # suit le fichier à travers ses renommages

git log -S, la « pioche », est le plus méconnu et le plus utile : il ne cherche pas dans les messages mais dans le contenu des modifications. Pour savoir quand une constante est apparue, ou quand un appel a disparu, c'est l'outil.

blame répond à « qui », -S répond à « quand et dans quel contexte ». Le second est presque toujours la meilleure question — et évite l'usage de blame comme instrument de reproche, qui est le meilleur moyen d'obtenir des commits sans message utile.

cherry-pick : reporter un correctif

git cherry-pick a91b4de

Applique le changement introduit par un commit, ailleurs. L'usage typique est le report d'un correctif de sécurité de main vers une branche de maintenance, sans emporter les fonctionnalités qui l'accompagnent.

Le commit créé a une autre empreinte : c'est un jumeau, pas le même. Ce qui explique un classique — fusionner ensuite la branche de maintenance peut produire un conflit, Git voyant deux changements sans lien qui touchent les mêmes lignes.

Le piège classique

Sur un dépôt très volumineux, sparse-checkout n'extrait qu'une partie de l'arborescence, et le clone partiel ne récupère les objets qu'à la demande. Ces options accélèrent réellement les postes et les runners — mais un script qui suppose l'arborescence complète échoue de façon obscure, sur des fichiers qui existent dans le dépôt sans être sur le disque.