Explorer l'historique d'un projet : commandes Git Log, Diff et Blame

Explorer l'historique d'un projet avec les commandes Git log, diff et blame vous aide à comprendre comment une base de code est arrivée à son état actuel. Lorsqu'un déploiement échoue, qu'un paramètre change ou qu'un fichier vous semble inconnu, ces commandes vous offrent une piste claire plutôt qu'un jeu de devinettes.

Vous n'avez pas besoin de mémoriser toutes les options de Git. Commencez par quelques motifs fiables, puis ajoutez des détails uniquement lorsque la situation l'exige.

Lire l'histoire avec Git Log

git log affiche l'historique des commits de votre branche actuelle. Par défaut, il imprime les hachages de commit, les auteurs, les dates et les messages de commit. C'est utile, mais cela peut être trop d'informations lorsque vous avez seulement besoin d'une chronologie rapide.

Pour le travail quotidien, ce format est plus facile à parcourir :

git log --oneline --decorate --graph --all

Cela montre une liste compacte de commits, des étiquettes de branche et un graphique simple des fusions. C'est particulièrement utile lorsque vous voulez voir si votre branche a divergé de main ou si un commit de fusion a apporté un groupe de modifications.

Si vous devez inspecter un fichier spécifique, limitez le log à ce chemin :

git log --oneline -- path/to/file

Cela répond à une question courante : "Qui a touché ce fichier récemment, et pourquoi ?" À partir de là, vous pouvez ouvrir un commit avec :

git show <commit>

git show affiche le message de commit et le patch pour ce commit. C'est une bonne étape suivante lorsqu'une entrée de log semble liée au problème que vous examinez.

Pour un exemple pratique, imaginez que votre application commence à expirer après un changement de configuration. Vous pourriez exécuter git log --oneline -- config/nginx.conf, trouver un commit nommé "increase upstream timeout", puis l'inspecter avec git show. Cela vous donne les lignes exactes modifiées et l'intention environnante du message de commit.

Pour les bases du workflow associé, voir maîtriser le stage et le commit Git.

Comparer les modifications avec Git Diff

git diff montre ce qui a changé entre deux états. C'est la commande que vous utilisez avant de commiter, avant de réviser une branche, ou lorsque vous vérifiez si une modification locale a causé un changement de comportement.

La version la plus courante est :

git diff

Cela compare votre arbre de travail avec la dernière version commitée. En termes simples, cela montre les modifications non indexées.

Si vous avez déjà indexé des fichiers avec git add, utilisez :

git diff --staged

Cela montre ce qui sera inclus dans le prochain commit. C'est l'une des meilleures habitudes que vous puissiez prendre car cela permet de détecter les modifications accidentelles d'espaces blancs, les instructions de débogage et les modifications non liées avant qu'elles ne fassent partie de l'historique du projet.

Vous pouvez également comparer deux branches :

git diff main..feature-branch

Cela montre ce qui est différent sur feature-branch par rapport à main. Si la sortie est trop volumineuse, limitez-la à un fichier :

git diff main..feature-branch -- src/server.js

Lors de la révision d'un patch, lisez d'abord les noms de fichiers, puis les blocs modifiés. Git marque les lignes supprimées avec - et les lignes ajoutées avec +. Les lignes inchangées à proximité sont du contexte, pas des modifications.

Un motif de dépannage utile consiste à comparer le dernier bon commit connu avec le commit actuel :

git diff <good-commit>..HEAD

Cela ne vous dira pas quelle ligne est cassée en soi, mais cela vous donne la zone de recherche. Lorsque le diff est petit, la cause est souvent évidente. Lorsqu'il est grand, vous aurez peut-être besoin de git bisect, de tests ou d'une révision ciblée.

Trouver la propriété des lignes avec Git Blame

git blame montre le dernier commit qui a modifié chaque ligne d'un fichier. Malgré son nom, la commande ne consiste pas à attribuer une faute. Il s'agit de trouver le contexte.

Utilisez-la comme ceci :

git blame path/to/file

Chaque ligne inclut un hachage de commit, un auteur, une date et un contenu. Si une ligne semble suspecte, copiez le hachage du commit et inspectez-le :

git show <commit>

Cela vous aide à poser de meilleures questions. Au lieu de demander "Pourquoi est-ce ici ?", vous pouvez demander "Cela a-t-il été ajouté pour un correctif de compatibilité, une solution de contournement de performance ou un patch d'urgence ?"

Pour les fichiers volumineux, la sortie de blame peut être bruyante. La plupart des terminaux vous permettent de la parcourir, mais vous pouvez également cibler une plage de lignes :

git blame -L 40,80 path/to/file

Cela maintient votre investigation ciblée. C'est idéal lorsqu'une trace de pile d'erreurs pointe vers une ligne spécifique.

Un détail compte : git blame montre le commit le plus récent qui a modifié une ligne, pas nécessairement le commit qui a introduit l'idée sous-jacente. Les commits de formatage peuvent rendre blame moins utile. Si votre équipe a un commit de formatage uniquement, vous devrez peut-être inspecter l'historique antérieur ou utiliser la configuration ignore-revs.

Un flux d'investigation pratique de l'historique

Lorsque quelque chose change et que vous ne savez pas pourquoi, utilisez les commandes dans un ordre stable.

1. Commencez par git status pour voir si vous avez des modifications locales.
2. Utilisez git diff ou git diff --staged pour inspecter les modifications non commitées.
3. Utilisez git log --oneline -- path/to/file pour trouver les commits récents pour un fichier.
4. Utilisez git show <commit> pour inspecter un changement probable.
5. Utilisez git blame -L start,end file lorsqu'une ligne a besoin de contexte.

Cela vous évite de sauter directement dans une énorme recherche d'historique. Vous commencez par ce qui a changé localement, puis vous élargissez la portée à l'historique de la branche et du fichier.

Par exemple, supposons qu'une construction Docker commence à échouer parce qu'une variable d'environnement a disparu. Vérifiez d'abord votre diff local. Si c'est propre, inspectez le log pour le Dockerfile et la configuration de déploiement. Si vous trouvez un commit qui a renommé la variable, git show révélera si le code de l'application a également été mis à jour. Si une référence reste peu claire, git blame peut montrer quand elle a changé pour la dernière fois.

Quand demander de l'aide

Les commandes d'historique Git sont sûres à exécuter car elles inspectent l'historique plutôt que de le réécrire. Néanmoins, demandez à un collègue avant de tirer une conclusion ferme d'un seul commit. Une ligne peut avoir été modifiée lors d'un refactoring, copiée d'un autre fichier, ou mise à jour pour contourner un problème de production qui n'est pas évident à partir du code.

Vous devriez également faire une pause avant d'utiliser des commandes de réécriture d'historique telles que rebase, reset ou filter-repo sur des branches partagées. Ce sont des outils utiles, mais ils peuvent perturber les autres développeurs s'ils sont utilisés sans coordination.

Git log, diff et blame vous offrent une visibilité pratique sur l'historique du projet. Utilisez log pour trouver la chronologie, diff pour comparer les modifications et blame pour tracer le contexte au niveau des lignes. Ensemble, ils transforment "quelque chose a changé" en un commit, un fichier et une raison spécifiques sur lesquels vous pouvez agir.