Pour trouver le commit qui a modifié une ligne pour la dernière fois dans un projet Git local sur votre Mac, ouvrez Terminal, déplacez-vous dans le dépôt et exécutez git blame sur le fichier avec la plage de numéros de ligne. Inspectez ensuite ce commit avec git show pour lire son message et son diff. Blame identifie la dernière modification apportée à la ligne actuelle ; cela ne révèle pas toujours quand la ligne est apparue pour la première fois ni pourquoi elle a été écrite.

1. Ouvrez le dépôt dans Terminal

Si vous avez déjà le projet ouvert dans le Finder, ouvrez Terminal et tapez cd , puis faites glisser le dossier du projet dans la fenêtre du Terminal et appuyez sur Retour. macOS insérera le chemin du dossier, ce qui évite les erreurs de saisie. Vous pouvez également entrer le chemin vous-même en l'entourant de guillemets s'il contient des espaces, par exemple :

cd "/Users/sam/Projects/My App"

Vérifiez que vous vous trouvez dans un arbre de travail Git et que Git est disponible :

git status --short
git --version

Si la première commande indique que le répertoire actuel n'est pas un dépôt Git, naviguez vers le véritable répertoire du dépôt du projet. Si git n'est pas disponible, installez ou activez Git via une configuration de confiance avant de continuer. Les commandes ci-dessous utilisent la syntaxe standard du shell et fonctionnent aussi bien dans le shell par défaut de Terminal sur macOS que dans d'autres shells courants.

2. Exécutez blame pour la ligne qui vous intéresse

Trouvez le numéro de ligne dans votre éditeur, puis remplacez le chemin du fichier et le numéro de ligne ci-dessous. Le chemin est relatif à la racine du dépôt ; entourez-le de guillemets s'il contient des espaces ou des métacaractères du shell.

git blame -L 42,42 -- "Sources/Settings.swift"

-L 42,42 restreint l'annotation à la ligne 42. Git commence la numérotation des lignes à 1. Pour inspecter le contexte environnant, utilisez une plage telle que -L 38,46. Git affiche un identifiant de commit, les détails de l'auteur, les informations de date et le texte de la ligne. Sa documentation décrit blame comme affichant la révision et l'auteur ayant modifié chaque ligne pour la dernière fois, et prend en charge la sélection de plages de lignes avec -L. Documentation de Git blame

Si vous ne connaissez pas le numéro de ligne, ouvrez le fichier dans votre éditeur et fiez-vous aux numéros de ligne affichés. Vous pouvez également annoter l'ensemble du fichier en omettant -L :

git blame -- "Sources/Settings.swift"

Si vous n'êtes pas à la racine du dépôt, utilisez un chemin relatif au répertoire depuis lequel vous avez exécuté la commande. Si Git indique que le chemin n'existe pas, vérifiez à la fois votre répertoire actuel (pwd) ainsi que la casse exacte et l'orthographe du chemin.

3. Lisez le commit identifié par blame

Copiez l'identifiant de commit affiché pour la ligne ciblée et passez-le à git show :

git show --format=fuller --stat a1b2c3d

Remplacez a1b2c3d par l'identifiant issu de votre résultat. Cela affiche les métadonnées du commit et un résumé des fichiers. Pour lire également le patch, omettez --stat :

git show --format=fuller a1b2c3d

Examinez les lignes modifiées autour de la ligne ciblée, le message de commit et les autres fichiers modifiés dans le même commit. Ces détails peuvent aider à expliquer le contexte de la modification. Un message de commit consigne ce que son auteur a rédigé ; il ne constitue pas une preuve de la justification de conception. Git documente git show comme affichant les informations du commit et son diff textuel. Documentation de Git show

Lorsque blame pointe vers un commit de formatage ou de déplacement

Une ligne a pu être touchée par une vaste opération de formatage, un renommage ou un déplacement de code. Dans ce cas, le commit désigné par blame n'est peut-être pas celui qui a introduit la logique à l'origine. Essayez la détection de déplacement et de copie :

git blame -M -C -L 42,42 -- "Sources/Settings.swift"

-M demande à Git de détecter les lignes déplacées au sein d'un même fichier, tandis que -C recherche également les lignes copiées ou déplacées depuis d'autres fichiers. Ces options aident Git à retracer certains refactorings, mais la détection repose sur la correspondance de contenu et peut ne pas résoudre tous les historiques. Documentation de Git blame

Si un dépôt comporte un fichier .git-blame-ignore-revs pour les modifications étendues telles que le formatage, vous pouvez demander à Git de l'utiliser :

git blame --ignore-revs-file .git-blame-ignore-revs -L 42,42 -- "Sources/Settings.swift"

Cela peut rendre la modification pertinente plus facile à repérer, mais les révisions ignorées affectent l'annotation ; inspectez le fichier d'ignorance du dépôt ou comparez avec une exécution de blame sans cette option si le résultat semble surprenant. La documentation de Git mentionne cette option, et GitHub documente la même convention de fichier pour ignorer des révisions. Documentation de Git blame

Ce que blame ne peut pas vous dire

Blame annote les lignes qui existent dans la version du fichier sélectionnée. Elle ne montre pas directement les lignes supprimées ou remplacées, et le commit de modification le plus récent peut différer de l'introduction initiale. Pour le texte supprimé ou les états antérieurs du fichier, inspectez les diffs de commits et l'historique ; la documentation de Git blame renvoie à git diff et aux recherches dans l'historique pour les modifications ayant retiré ou remplacé du contenu. Documentation de Git blame

Si le dépôt est hébergé sur GitHub et que vous y avez accès, vous pouvez également ouvrir le fichier et sélectionner Blame pour afficher l'historique ligne par ligne dans le navigateur. Cliquez sur un message de commit pour inspecter cette modification, ou utilisez le sélecteur de versions pour afficher le fichier dans son état antérieur. GitHub Docs : Affichage et compréhension des fichiers

Sources