Comment grep (rechercher) du code engagé dans l'historique Git

J'ai supprimé un fichier ou du code dans un fichier dans le passé. Puis-je grep dans le contenu (pas dans les messages de commit)?

Une très mauvaise solution consiste à grep le journal:

git log -p | grep <pattern>

Cependant, cela ne renvoie pas immédiatement le hachage de validation. J'ai joué git grepsans succès.

Pour rechercher du contenu de validation (c'est-à-dire des lignes de source réelles, par opposition aux messages de validation et autres), vous devez faire:

git grep <regexp> $(git rev-list --all)

git rev-list --all | xargs git grep <expression> fonctionnera si vous rencontrez une erreur "Liste d'arguments trop longue".

Si vous voulez limiter la recherche à un sous-arbre (par exemple, "lib / util"), vous devrez le passer à la rev-listsous-commande et grepaussi:

git grep <regexp> $(git rev-list --all -- lib/util) -- lib/util

Cela va parcourir tout votre texte de validation pour regexp.

La raison du passage du chemin dans les deux commandes est parce rev-listque renverra la liste des révisions où toutes les modifications se sont lib/utilproduites, mais vous devez également passer à grepafin qu'il ne recherche que lib/util.

Imaginez simplement le scénario suivant: greppourrait trouver la même chose <regexp>sur d'autres fichiers qui sont contenus dans la même révision retournée par rev-list(même s'il n'y a eu aucune modification de ce fichier sur cette révision).

Voici d'autres moyens utiles de rechercher votre source:

Rechercher dans l'arborescence de travail le texte correspondant à l'expression rationnelle expression régulière:

git grep <regexp>

Recherchez dans l'arborescence de travail des lignes de texte correspondant à l'expression régulière regexp1 ou regexp2:

git grep -e <regexp1> [--or] -e <regexp2>

Recherchez dans l'arborescence de travail les lignes de texte correspondant aux expressions régulières regexp1 et regexp2, en signalant uniquement les chemins d'accès aux fichiers:

git grep -l -e <regexp1> --and -e <regexp2>

Recherchez dans l'arborescence de travail des fichiers contenant des lignes de texte correspondant à l'expression régulière regexp1 et des lignes de texte correspondant à l'expression régulière regexp2:

git grep -l --all-match -e <regexp1> -e <regexp2>

Recherchez dans l'arbre de travail les lignes modifiées du modèle de correspondance de texte:

git diff --unified=0 | grep <pattern>

Rechercher toutes les révisions pour le texte correspondant à l'expression rationnelle expression régulière:

git grep <regexp> $(git rev-list --all)

Rechercher toutes les révisions entre rev1 et rev2 pour le texte correspondant à l'expression régulière expression régulière:

git grep <regexp> $(git rev-list <rev1>..<rev2>)

Vous devez utiliser l' option pickaxe ( -S) de git log.

Pour rechercher Foo:

git log -SFoo -- path_containing_change
git log -SFoo --since=2009.1.1 --until=2010.1.1 -- path_containing_change

Voir l' historique Git - recherchez la ligne perdue par mot-clé pour en savoir plus.

Comme l'a commenté Jakub Narębski :

• cela recherche les différences qui introduisent ou suppriment une instance de<string> . Cela signifie généralement "révisions où vous avez ajouté ou supprimé la ligne avec 'Foo'".

• l' --pickaxe-regexoption vous permet d'utiliser l'expression régulière POSIX étendue au lieu de rechercher une chaîne. Exemple (de git log):git log -S"frotz\(nitfol" --pickaxe-regex

Comme Rob l'a commenté, cette recherche est sensible à la casse - il a ouvert une question de suivi sur la façon de rechercher sans tenir compte de la casse.

Ma façon préférée de le faire est avec git logl' -Goption de (ajoutée dans la version 1.7.4).

-G<regex>
       Look for differences whose added or removed line matches the given <regex>.

Il existe une différence subtile entre la façon dont les options -Get -Sdéterminent si une validation correspond:

• L' -Soption compte essentiellement le nombre de fois que votre recherche correspond dans un fichier avant et après une validation. La validation est affichée dans le journal si les décomptes avant et après sont différents. Cela ne montrera pas, par exemple, les commits où une ligne correspondant à votre recherche a été déplacée.
• Avec l' -Goption, la validation est affichée dans le journal si votre recherche correspond à une ligne ajoutée, supprimée ou modifiée.

Prenez ce commit comme exemple:

diff --git a/test b/test
index dddc242..60a8ba6 100644
--- a/test
+++ b/test
@@ -1 +1 @@
-hello hello
+hello goodbye hello

Étant donné que le nombre de fois où "bonjour" apparaît dans le fichier est le même avant et après cette validation, il ne correspondra pas à l'utilisation -Shello. Cependant, comme il y a eu un changement dans une correspondance de ligne hello, le commit sera affiché en utilisant-Ghello .

Si vous voulez parcourir les changements de code (voir ce qui a réellement été changé avec le mot donné dans toute l'histoire), optez pour le patchmode - j'ai trouvé une combinaison très utile de faire:

git log -p
# Hit '/' for search mode.
# Type in the word you are searching.
# If the first search is not relevant, hit 'n' for next (like in Vim ;) )

git log peut être un moyen plus efficace de rechercher du texte dans toutes les branches, en particulier s'il existe de nombreuses correspondances, et que vous souhaitez voir les modifications les plus récentes (pertinentes) en premier.

git log -p --all -S 'search string'
git log -p --all -G 'match regular expression'

Ces commandes de liste des commandes de journalisation ajoutent ou suppriment la chaîne de recherche / l'expression régulière donnée (généralement) la plus récente en premier. L' -poption permet d'afficher le diff correspondant à l'endroit où le modèle a été ajouté ou supprimé, afin que vous puissiez le voir dans son contexte.

Après avoir trouvé une validation pertinente qui ajoute le texte que vous recherchez (par exemple, 8beeff00d), recherchez les branches qui contiennent la validation:

git branch -a --contains 8beeff00d

J'ai pris la réponse de Jeet et l' ai adaptée à Windows (grâce à cette réponse ):

FOR /F %x IN ('"git rev-list --all"') DO @git grep <regex> %x > out.txt

Notez que pour moi, pour une raison quelconque, la validation réelle qui a supprimé cette expression régulière n'apparaissait pas dans la sortie de la commande, mais plutôt une validation avant celle-ci.

Rechercher dans n'importe quelle révision, n'importe quel fichier :

git rev-list --all | xargs git grep <regexp>

Rechercher uniquement dans certains fichiers donnés, par exemple des fichiers XML:

git rev-list --all | xargs -I{} git grep <regexp> {} -- "*.xml"

Les lignes de résultat doivent ressembler à ceci: 6988bec26b1503d45eb0b2e8a4364afb87dde7af: bla.xml: texte de la ligne trouvée ...

Vous pouvez ensuite obtenir plus d'informations comme l'auteur, la date et la différence en utilisant git show:

git show 6988bec26b1503d45eb0b2e8a4364afb87dde7af

Pour plus de simplicité, je suggère d'utiliser GUI: gitk - Le navigateur du référentiel Git . C'est assez flexible

1. Pour rechercher le code:
   
   
2. Pour rechercher des fichiers:
   
   
3. Bien sûr, il prend également en charge les expressions régulières:
   
   

Et vous pouvez parcourir les résultats à l'aide des flèches haut / bas.

Pour toute autre personne essayant de le faire dans Sourcetree , il n'y a pas de commande directe dans l'interface utilisateur (à partir de la version 1.6.21.0). Cependant, vous pouvez utiliser les commandes spécifiées dans la réponse acceptée en ouvrant Terminal fenêtre (bouton disponible dans la barre d'outils principale) et en les copiant / collant.

Remarque: la vue Recherche de Sourcetree peut partiellement effectuer une recherche de texte pour vous. Appuyez sur Ctrl+ 3pour accéder à la vue Recherche (ou cliquez sur l'onglet Recherche disponible en bas). À l'extrême droite, définissez Type de recherche sur Modifications de fichier , puis tapez la chaîne que vous souhaitez rechercher. Cette méthode présente les limitations suivantes par rapport à la commande ci-dessus:

1. Sourcetree ne montre que les commits qui contiennent le mot de recherche dans l' un des fichiers modifiés. La recherche du fichier exact qui contient le texte de recherche est à nouveau une tâche manuelle.
2. RegEx n'est pas pris en charge.

Chaque fois que je me retrouve chez vous, j'utilise la ligne de commande suivante:

git log -S "<words/phrases i am trying to find>" --all --oneline  --graph

Explication:

1. git log- Dois-je écrire plus ici; il montre les journaux par ordre chronologique.
2. -S "<words/phrases i am trying to find>" - Il montre tous ces commits Git où n'importe quel fichier (ajouté / modifié / supprimé) a les mots / phrases que j'essaye de trouver sans les symboles '<>'.
3. --all - Pour appliquer et rechercher dans toutes les branches.
4. --oneline - Il comprime le journal Git sur une seule ligne.
5. --graph - Il crée le graphique des validations chronologiquement ordonnées.

La réponse de Jeet fonctionne dans PowerShell.

git grep -n <regex> $(git rev-list --all)

Ce qui suit affiche tous les fichiers, dans n'importe quel commit, qui contiennent un fichier password.

# Store intermediate result
$result = git grep -n "password" $(git rev-list --all)

# Display unique file names
$result | select -unique { $_ -replace "(^.*?:)|(:.*)", "" }

Alors, essayez-vous de parcourir les anciennes versions du code pour voir où quelque chose existe en dernier?

Si je faisais cela, j'utiliserais probablement git bissect . En utilisant bisect, vous pouvez spécifier une bonne version connue, une mauvaise version connue et un script simple qui vérifie si la version est bonne ou mauvaise (dans ce cas, un grep pour voir si le code que vous recherchez est présent ). L'exécution de cette fonction détectera la date de suppression du code.

Scénario: vous avez fait un grand nettoyage de votre code en utilisant votre IDE. Problème: l'EDI a nettoyé plus qu'il ne le devrait et maintenant votre code ne compile pas (ressources manquantes, etc.)

Solution:

git grep --cached "text_to_find"

Il trouvera le fichier où "text_to_find" a été modifié.

Vous pouvez maintenant annuler cette modification et compiler votre code.

git rev-list --all | xargs -n 5 git grep EXPRESSION

est un ajustement à la solution de Jeet , donc il montre les résultats pendant qu'il recherche et pas seulement à la fin (ce qui peut prendre beaucoup de temps dans un grand référentiel).

Dans mon cas, je devais rechercher un court commit et les solutions listées ne fonctionnaient malheureusement pas.

J'ai réussi à le faire avec (remplacer le token REGEX ):

for commit in $(git rev-list --all --abbrev-commit)
do
    if [[ $commit =~ __REGEX__ ]]; then 
        git --no-pager show -s --format='%h %an - %s' $commit
    fi
done