Rechercher quand et où les lignes de code ont été ajoutées à votre base de code peut être un casse-tête, mais Git stocke toutes changelogs, et dispose de quelques outils pour rechercher dans les différences de validation. Vous pouvez les utiliser pour trouver 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 le traitement de la sortie est un peu lourd.
Dans tous les cas, l'affichage interactif du pager de Git est assez maladroit pour de nombreuses personnes, nous vous recommandons donc soit de rechercher dans la barre de commandes avec /Search, soit de rediriger 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 un référentiel entier 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 à mettre la chaîne de recherche juste après sans espace.
git log –after=”6 week” – S'Dictionary' –stat
Publicité
Si vous souhaitez afficher les fichiers avec cette sortie, vous pouvez utiliser le -p flag :
git log –after=”6 week” -S'Dictionary' –stat -p | chat
Cependant, cette sortie est massive pour toute requête volumineuse et n'est pas très différente de la simple ouverture dans votre IDE. Pour résoudre ce problème, nous devrons utiliser grep et sed, ce qui signifie que les commandes vont malheureusement devenir compliquées.
Utiliser sed pour plus d'intelligence Correspondance
Pour faire correspondre et imprimer les lignes réelles du fichier, vous devrez utiliser grep, en lui redirigeant la sortie pour imprimer les lignes sur lesquelles il a trouvé le motif. Cela nécessite que vous tapiez le motif deux fois :
git log –after=”6 week” -S'Dictionary' –stat -p | grep 'Dictionnaire'
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 décomposer sed :
SEARCH=Dictionary && git log –after=”6 semaines” -S$SEARCH –stat -p | sed -n “/commit/,/diff/p; /$RECHERCHE/p”
Cette commande définit une variable SEARCH, car taper deux fois le terme de recherche est fastidieux. Il exécute git log –stat -p, qui imprime la sortie complète, mais il est transmis à sed pour l'analyse. sed correspond à toutes les lignes entre “commit” et “diff,” qui récupère la sortie d'en-tête –stat. 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 voulez simplement comprendre l'historique de celui-ci, vous pouvez utiliser git Blame.
Publicité
Git-blame imprimera le fichier entier, mais annotez chaque ligne avec la personne qui l'a modifiée en dernier. Cela vous permettra de suivre rapidement les changements et, dans de nombreux cas, de rejeter la faute sur vos collègues.
Vous pouvez utiliser la commande git blâme, mais GitHub dispose d'une excellente interface graphique pour cela, disponible en cliquant sur le bouton fichier en question et en appuyant sur “Blame.”
Notez que vous peut également afficher l'historique chronologique du fichier à partir de la même interface ; Git blâme condense tout sur une seule sortie.