Explorer l'historique des commits
L'historique des commits est la colonne vertébrale de tout dépôt Git. Il enregistre ce qui a changé, quand et par qui. Les trois commandes ci-dessous vous permettent de lire cet historique à différents niveaux de zoom : la chronologie complète, un instantané unique ou un résumé par contributeur.
git log — Parcourir la chronologie
git log est le point de départ de toute investigation. Par défaut, il liste chaque commit du plus récent au plus ancien. Combinez-le avec --oneline, --graph, --author et --since / --until pour cibler ce qui compte.
Approfondir : git log expliqué.
git show — Inspecter un commit
Une fois que vous avez repéré un commit avec git log, zoomez dessus avec git show <hash>. Il affiche les métadonnées (auteur, date, message) et le diff complet en une seule sortie.
Approfondir : git show expliqué.
git shortlog — Résumer 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é.
Rechercher dans le code
Parfois, vous savez ce que vous cherchez mais pas où cela se trouve. git grep fouille la base de code actuelle tandis que git log -S (le « pickaxe ») trouve quand une chaîne 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é.
git log -S (pickaxe) — Trouver quand une chaîne a été ajoutée ou supprimée
Le flag -S (le « pickaxe ») filtre git log pour ne garder que les commits où la chaîne donnée apparaît dans le diff. Si une fonction a été supprimée et que vous voulez savoir quand, git log -S "nomDeFonction" vous mène directement au commit responsable.
Trouver qui a modifié quoi
Retracer les auteurs vous aide à comprendre les décisions de code et à demander du contexte à la bonne personne. git blame donne des annotations ligne par ligne ; git log -p montre l'évolution 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ère modification. C'est le moyen le plus rapide de répondre à « qui a écrit cette ligne et pourquoi ? » Utilisez -L 10,20 pour limiter la plage, ou -C pour détecter le code déplacé depuis d'autres fichiers.
Approfondir : git blame expliqué.
git log -p — Suivre les modifications d'un fichier
Alors que git blame montre l'état actuel, git log -p -- <fichier> affiche chaque commit qui a touché ce fichier avec le diff complet. C'est le meilleur moyen de voir comment un fichier a évolué au fil du temps.
Trouver le bug
Quand une régression 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'état actuel comme bad et un commit fonctionnel connu comme good. Git extrait le commit du point milieu pour que vous le testiez. En quelques étapes seulement, même sur des centaines de commits, il isole le commit exact qui a cassé le code. Terminez avec git bisect reset.
Approfondir : git bisect expliqué.
Le workflow de debug
Chaque commande résout un problème précis. Combinées, elles forment un workflow de debug systématique. Voici le processus en quatre étapes que suivent les développeurs expérimentés quand quelque chose casse.
Étape 1
Réduire la période
Utilisez git log --oneline --since pour identifier la plage de commits où le bug a pu être introduit. Filtrez par date, auteur ou chemin de fichier pour réduire la liste.
Étape 2
Identifier l'auteur
Exécutez git blame <fichier> sur le fichier suspect pour voir qui a modifié les lignes en question en dernier. Cela vous oriente vers la personne qui a le plus de contexte.
Étape 3
Localiser le commit
Lancez git bisect entre un état fonctionnel connu et l'état défaillant actuel. En quelques étapes, Git isole le commit exact qui a introduit la régression.
Étape 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é, quand et pourquoi.
Ce workflow fonctionne aussi bien pour un projet personnel que pour une grande équipe avec des milliers de commits. L'idée clé : vous n'avez jamais besoin de lire chaque commit. Chaque outil réduit progressivement l'espace de recherche jusqu'à ce que vous regardiez le seul commit qui compte.