Rechercher du code avec GitHub, Sourcegraph et Git local

Commencez la recherche de code en fixant le dépôt et le périmètre des fichiers, puis examinez l’implémentation trouvée dans son contexte. Un nom de symbole correspondant est une piste, pas la preuve que le code convient à votre version de dépendance ou au comportement voulu.

La recherche GitHub, Sourcegraph et un checkout local interrogent des données disponibles différentes. Utilisez l’outil qui peut accéder au dépôt nécessaire ; ne supposez pas qu’une instance publique indexe chaque dépôt ou révision.

Déroulement

Limiter la requête avant d’élargir la liste des résultats. Si la version compte, ouvrir la révision voulue ou rechercher dans son checkout plutôt que se fier à la branche par défaut.

Utiliser le langage de requête de chaque service

Une requête de recherche GitHub peut combiner ces qualificatifs avec une expression entre guillemets :

repo:spring-projects/spring-framework language:java path:WebClient.java "interface WebClient"

Les filtres Sourcegraph correspondants utilisent des expressions régulières pour le dépôt et le fichier :

repo:^github\.com/spring-projects/spring-framework$ lang:java file:WebClient\.java$ "interface WebClient"

Intention	Recherche GitHub	Sourcegraph
Dépôt	repo:owner/name	Expression régulière repo: ; ancrer si l’exactitude compte
Java	language:java	lang:java ou language:java
Périmètre des fichiers	Filtre de chemin path:	Expression régulière file:
Expression exacte	Expression entre guillemets	Expression entre guillemets en mode mots-clés

Ce sont des exemples de construction de requêtes, pas des mesures du nombre de résultats en direct. Les deux filtres de chemin ne renvoient pas forcément les mêmes ensembles : l’exemple Sourcegraph ancre le suffixe du nom de fichier. L’accès, le contenu indexé et la révision choisie déterminent aussi ce qui est trouvable.

Reproduire la recherche locale dans un répertoire vide

Ce petit exemple nécessite Git et un shell POSIX. mkdir échoue volontairement si demo-search existe déjà ; choisissez donc un nouveau répertoire de travail.

set -eu
mkdir demo-search
cd demo-search
git init -q
mkdir src docs
printf '%s\n' 'interface WebClient {}' > src/WebClient.java
printf '%s\n' 'interface WebClient is discussed here' > docs/notes.txt
git add src docs
git grep -n -F 'interface WebClient' -- src

Sortie :

src/WebClient.java:1:interface WebClient {}

La même expression existe dans docs/notes.txt, mais -- src limite la recherche. git grep -F traite le motif comme une chaîne fixe et -n affiche les numéros de ligne. Les fichiers ont été ajoutés à l’index parce que la recherche par défaut dans l’arbre de travail utilise les fichiers suivis ; l’exemple ne crée aucun commit. Dans un vrai checkout, remplacez le chemin et le motif en conservant le périmètre voulu.

Avant d’adapter un résultat, lisez les appelants, les tests, la licence et la révision. Une même déclaration peut se comporter différemment dans une autre version. Utilisez les tests de réponses WebClient pour vérifier un contrat client plutôt que déduire son comportement d’un résultat de recherche.