Confirmer et expliquer le commit fautif

Une recherche automatisée vous donne une révision candidate, mais ce résultat ne suffit pas à expliquer l’incident. Vous devez vérifier que le changement correspond au défaut observé et que la révision précédente ne le présente pas. Cette confirmation transforme un résultat de recherche en diagnostic vérifiable par l’équipe.

Dans la leçon précédente, vous avez confié le verdict à git bisect run. Ici, vous n’élargissez pas la recherche : vous examinez la révision que Git a désignée, puis vous vérifiez la frontière entre le dernier état sain et le premier état défectueux. Conservez la session bisect active le temps de relever cette révision ; vous pourrez la terminer après avoir enregistré le résultat.

Examiner la révision candidate

Quand git bisect run termine sa recherche, HEAD se trouve sur le commit identifié. Enregistrez son identifiant complet avant de réinitialiser la session. Les commandes suivantes recueillent les métadonnées et le résumé des fichiers modifiés ; elles ne changent pas le contenu du dépôt.

coupable=$(git rev-parse HEAD)
printf 'Commit candidat : %s\n' "$coupable"
git show --format=fuller --stat "$coupable"

Commit candidat : <identifiant du commit>
commit <identifiant du commit>
Author: …
Date: …
    <message de commit>

 index.html | …

Le résumé permet de repérer rapidement les fichiers touchés, mais il ne prouve pas le lien avec le défaut. Affichez le diff complet et cherchez le changement qui peut expliquer précisément le résultat observé : par exemple, une modification de la cible d’un lien, d’un titre ou d’un élément attendu par le test. Dans le dépôt du site devenu produit, le contenu pertinent est souvent dans index.html ; ne concluez pas à partir du seul nom du commit.

git show --format=fuller --find-renames "$coupable"

Métadonnées du commit, suivies du diff complet. Les lignes précédées de - sont supprimées ; celles précédées de + sont ajoutées.

Comparer le commit et son parent

Le test doit confirmer la frontière signalée : le parent du commit est sain, tandis que le commit candidat est défectueux. Le parent est accessible avec la référence coupable^. Affichez son identifiant et le diff limité à index.html pour vérifier si le changement suspect apparaît à cet endroit.

parent=$(git rev-parse "$coupable^")
printf 'Parent : %s\n' "$parent"
git diff "$parent" "$coupable" -- index.html

Parent : <identifiant du commit parent>
Diff des changements apportés à index.html entre le parent et le commit candidat.

Inspecter le diff ne remplace pas le test reproductible déjà préparé. Exécutez ce même test sur le commit candidat, puis sur son parent, dans des copies de travail séparées si vous devez changer de révision : le candidat doit échouer et le parent réussir. Gardez identiques la commande, les données d’entrée et les conditions d’exécution ; sinon, la comparaison ne permet pas d’attribuer le défaut au changement. Si le test ne donne pas ces deux résultats, vérifiez le périmètre temporel de la recherche et les éventuelles conditions nécessaires à la reproduction avant de retenir une cause.

Rédiger un compte rendu vérifiable

Le compte rendu doit permettre à une autre personne de refaire la vérification sans interpréter votre conclusion. Indiquez l’identifiant du commit candidat, son message, le fichier et la modification en cause, ainsi que les résultats du même test sur le commit et son parent. Ajoutez la commande ou les étapes de reproduction déjà utilisées et précisez toute limite rencontrée. Séparez les faits observés de l’explication proposée : cela évite de présenter une hypothèse comme une preuve.

• Relevez l’identifiant du commit désigné avant de terminer la session de recherche.
• Inspectez le diff et reliez la modification à l’observation reproductible.
• Vérifiez le résultat sur le commit et son parent avec le même test.
• Consignez les révisions, les résultats, les commandes et les limites du diagnostic.

Dans la suite, vous aborderez la récupération de références après une erreur Git, en commençant par la lecture du reflog local.