Comment rechercher dans les récents changements de Git Commit –

Trouver quand et où les lignes de code ont été ajoutées à votre base de code peut être un casse-tête, mais Git stocke tous les journaux des modifications et dispose de quelques outils pour rechercher dans les différences de validation. Vous pouvez les utiliser pour rechercher des lignes correspondant à une chaîne de recherche donnée.

Utiliser Git Log

Malheureusement, des sites comme GitHub n’offrent pas cette fonctionnalité, vous devrez donc utiliser git log. Cette commande a beaucoup de paramètres, y compris la possibilité de rechercher dans les différences de validation, mais la gestion de la sortie est un peu lourde.

Dans tous les cas, l’affichage du pager interactif de Git est assez maladroit pour de nombreuses personnes, nous vous recommandons donc de rechercher dans la barre de commandes avec /Search, ou diriger la sortie directement vers la console avec | cat, ou dans un fichier avec > log.txt, où il peut être recherché plus efficacement.

L’exécution de ce type de recherche sur l’ensemble d’un référentiel générera probablement une sortie très importante. Vous voulez probablement voir les commits dans une plage de temps donnée, ce que vous pouvez faire avec --after et --before, qui prennent des dates ainsi que des dates relatives telles que « 2 semaines » et « 3 mois ». La commande suivante ignore les commits datant de plus d’un mois et demi, et ignore également les commits très récents.

git log --after="6 week" --before="1 week"

Si vous voulez simplement savoir quels commits contiennent une chaîne de recherche donnée, vous pouvez utiliser -S, ce qui vous oblige à placer la chaîne de recherche juste après, sans espace.

git log --after="6 week" -S'Dictionary' --stat

Si vous souhaitez afficher les fichiers avec cette sortie, vous pouvez utiliser le -p drapeau:

git log --after="6 week" -S'Dictionary' --stat -p | cat

Cependant, cette sortie est massif pour toute grande requête, et n’est pas très différent de simplement l’ouvrir dans votre IDE. Pour résoudre ce problème, nous devrons utiliser grep et sed, ce qui signifie que les commandes vont malheureusement se compliquer.

Utiliser sed pour une correspondance plus intelligente

Pour faire correspondre et imprimer les lignes réelles du fichier, vous devrez utiliser grep, lui redirigeant la sortie pour imprimer les lignes sur lesquelles il a trouvé le motif. Cela vous oblige à taper le modèle deux fois :

git log --after="6 week" -S'Dictionary' --stat -p | grep 'Dictionary'

Cependant, cela pose un problème : il n’inclut plus les messages de validation ou les identifiants. Pour résoudre ce problème, nous devons sortir sed:

SEARCH=Dictionary && git log --after="6 week" -S$SEARCH --stat -p | sed -n "/commit/,/diff/p; /$SEARCH/p"

Cette commande définit un SEARCH variable, car taper deux fois le terme de recherche est fastidieux. ça marche git log --stat -p, qui imprime la sortie complète, mais elle est transmise à sed pour l’analyse. sed correspond à toutes les lignes entre « commit » et « diff », qui saisit le --stat sortie d’en-tête. Ensuite, il ajoute la ligne qui correspond, produisant une sortie réellement utilisable.

Peut-être utiliser Git Blame à la place

Les exemples ci-dessus fonctionnent bien pour rechercher dans une base de code entière. Mais, si vous savez quel fichier est affecté et que vous souhaitez simplement en comprendre l’historique, vous pouvez utiliser git blame.

Git-blame imprimera le fichier entier, mais annotera chaque ligne avec la personne qui l’a modifié en dernier. Cela vous permettra de repérer rapidement les changements et, dans de nombreux cas, de rejeter la faute sur vos collègues.

Vous pouvez utiliser le git blame commande, mais GitHub dispose d’une excellente interface graphique, disponible en cliquant sur le fichier en question et en appuyant sur « Blame ».

Notez que vous pouvez également afficher l’historique chronologique du fichier à partir de la même interface ; Git blâme condense tout sur une seule sortie.