Explorer l'historique des commits
L'historique des commits est la colonne vert\u00e9brale de tout d\u00e9p\u00f4t Git. Il enregistre ce qui a chang\u00e9, quand et par qui. Les trois commandes ci-dessous vous permettent de lire cet historique \u00e0 diff\u00e9rents niveaux de zoom : la chronologie compl\u00e8te, un instantan\u00e9 unique ou un r\u00e9sum\u00e9 par contributeur.
git log — Parcourir la chronologie
git log est le point de d\u00e9part de toute investigation. Par d\u00e9faut, il liste chaque commit du plus r\u00e9cent au plus ancien. Combinez-le avec --oneline, --graph, --author et --since / --until pour cibler ce qui compte.
Approfondir : git log expliqu\u00e9.
git show — Inspecter un commit
Une fois que vous avez rep\u00e9r\u00e9 un commit avec git log, zoomez dessus avec git show <hash>. Il affiche les m\u00e9tadonn\u00e9es (auteur, date, message) et le diff complet en une seule sortie.
Approfondir : git show expliqu\u00e9.
git shortlog — R\u00e9sumer par auteur
git shortlog -s -n compte les commits par auteur et trie du plus actif au moins actif. C'est parfait pour les notes de version, les revues de code ou la prise en main d'un projet inconnu.
Approfondir : git shortlog expliqu\u00e9.
Rechercher dans le code
Parfois, vous savez ce que vous cherchez mais pas o\u00f9 cela se trouve. git grep fouille la base de code actuelle tandis que git log -S (le « pickaxe ») trouve quand une cha\u00eene est apparue ou a disparu dans l'historique.
git grep — Rechercher dans l'arbre de travail
git grep est plus rapide que grep -r car il ne cherche que dans les fichiers suivis et respecte votre .gitignore. Limitez la recherche par type de fichier avec -- "*.js", ciblez une branche, ou cherchez dans tous les commits avec --all.
Approfondir : git grep expliqu\u00e9.
git log -S (pickaxe) — Trouver quand une cha\u00eene a \u00e9t\u00e9 ajout\u00e9e ou supprim\u00e9e
Le flag -S (le « pickaxe ») filtre git log pour ne garder que les commits o\u00f9 la cha\u00eene donn\u00e9e appara\u00eet dans le diff. Si une fonction a \u00e9t\u00e9 supprim\u00e9e et que vous voulez savoir quand, git log -S "nomDeFonction" vous m\u00e8ne directement au commit responsable.
Trouver qui a modifi\u00e9 quoi
Retracer les auteurs vous aide \u00e0 comprendre les d\u00e9cisions de code et \u00e0 demander du contexte \u00e0 la bonne personne. git blame donne des annotations ligne par ligne ; git log -p montre l'\u00e9volution d'un fichier au fil du temps.
git blame — Auteur ligne par ligne
git blame <fichier> annote chaque ligne avec le hash du commit, l'auteur et la date de la derni\u00e8re modification. C'est le moyen le plus rapide de r\u00e9pondre \u00e0 « qui a \u00e9crit cette ligne et pourquoi ? » Utilisez -L 10,20 pour limiter la plage, ou -C pour d\u00e9tecter le code d\u00e9plac\u00e9 depuis d'autres fichiers.
Approfondir : git blame expliqu\u00e9.
git log -p — Suivre les modifications d'un fichier
Alors que git blame montre l'\u00e9tat actuel, git log -p -- <fichier> affiche chaque commit qui a touch\u00e9 ce fichier avec le diff complet. C'est le meilleur moyen de voir comment un fichier a \u00e9volu\u00e9 au fil du temps.
Trouver le bug
Quand une r\u00e9gression se glisse dans le code et que vous ne savez pas quel commit en est la cause, git bisect utilise une recherche dichotomique pour ne tester que log2(n) commits au lieu de tous les parcourir.
git bisect — Recherche dichotomique de bugs
Commencez par git bisect start, marquez l'\u00e9tat actuel comme bad et un commit fonctionnel connu comme good. Git extrait le commit du point milieu pour que vous le testiez. En quelques \u00e9tapes seulement, m\u00eame sur des centaines de commits, il isole le commit exact qui a cass\u00e9 le code. Terminez avec git bisect reset.
Approfondir : git bisect expliqu\u00e9.
Le workflow de debug
Chaque commande r\u00e9sout un probl\u00e8me pr\u00e9cis. Combin\u00e9es, elles forment un workflow de debug syst\u00e9matique. Voici le processus en quatre \u00e9tapes que suivent les d\u00e9veloppeurs exp\u00e9riment\u00e9s quand quelque chose casse.
\u00c9tape 1
R\u00e9duire la p\u00e9riode
Utilisez git log --oneline --since pour identifier la plage de commits o\u00f9 le bug a pu \u00eatre introduit. Filtrez par date, auteur ou chemin de fichier pour r\u00e9duire la liste.
\u00c9tape 2
Identifier l'auteur
Ex\u00e9cutez git blame <fichier> sur le fichier suspect pour voir qui a modifi\u00e9 les lignes en question en dernier. Cela vous oriente vers la personne qui a le plus de contexte.
\u00c9tape 3
Localiser le commit
Lancez git bisect entre un \u00e9tat fonctionnel connu et l'\u00e9tat d\u00e9faillant actuel. En quelques \u00e9tapes, Git isole le commit exact qui a introduit la r\u00e9gression.
\u00c9tape 4
Comprendre la modification
Utilisez git show <hash> sur le commit fautif pour voir le diff complet, le message du commit et l'auteur. Vous savez maintenant ce qui a cass\u00e9, quand et pourquoi.
Ce workflow fonctionne aussi bien pour un projet personnel que pour une grande \u00e9quipe avec des milliers de commits. L'id\u00e9e cl\u00e9 : vous n'avez jamais besoin de lire chaque commit. Chaque outil r\u00e9duit progressivement l'espace de recherche jusqu'\u00e0 ce que vous regardiez le seul commit qui compte.