Comment faire des recherches dans l’historique des dépôts et l’organiser à l’aide de GitHub
Ici, nous allons expliquer comment vous pouvez utiliser les filtres, les responsabilités et les références croisées pour organiser l’historique des dépôts et y faire des recherches.
Mettez-vous à la place d’un développeur qui vient de rejoindre l’équipe d’un projet de grande envergure. Une personne vient de poster un nouveau problème pour signaler un bogue lié à la barre latérale de l’application web et c’est à vous qu’il revient de corriger ce bogue. Vous avez déjà lu le rapport plusieurs fois pour comprendre le problème décrit. Vous devez donc maintenant déterminer la manière dont vous allez appréhender le correctif.
Comme vous êtes un nouveau membre de l’équipe, vous ne connaissez pas encore très bien le codebase. Vous n’avez pas non plus participé aux discussions sur la planification, aux revues du code ou aux autres tâches pouvant vous donner le contexte nécessaire pour démarrer l’implémentation. Vous devez d’abord acquérir ces connaissances générales pour déterminer au mieux le correctif approprié.
Recherche dans GitHub
Même si vous n’étiez pas encore là lors des événements qui ont mené à l’implémentation de la barre latérale, nombre d’entre eux sont conservés dans l’historique du projet. Commencez donc par rechercher « barre latérale » dans le dépôt du projet.
Deux méthodes de recherche sont disponibles sur GitHub : la recherche globale en haut de la page et la recherche ciblée sous certains onglets de dépôt. Elles prennent en charge la même syntaxe et fonctionnent de la même manière, mais avec quelques différences clés.
Recherche globale
La recherche globale vous permet d’utiliser la syntaxe de recherche complète pour rechercher dans tout GitHub.
Les résultats de la recherche sont complets et incluent tout ce qui va du code aux problèmes, en passant par la Place de marché et même les utilisateurs. Il s’agit de la meilleure façon de trouver des mentions des termes clés dans plusieurs types de résultats et dépôts.
Notes
La clause de filtre is:pr permet de filtrer les problèmes issus du magasin de problèmes/demandes de tirage (pull requests). Certaines clauses de filtre, comme is:pr, sont prises en charge uniquement par certains fournisseurs de recherche et ignorées par d’autres. Par exemple, le fournisseur de recherche de code ne prend pas en charge cette clause, il va donc l’ignorer et retourne les mêmes résultats de code dans les deux cas.
Dans notre scénario, l’utilisation de la recherche globale délimitée au dépôt actuel est un bon moyen de trouver du code et des commits qui mentionnent le terme « barre latérale ». Vous allez probablement aussi obtenir des accès aux problèmes et demandes de tirage, même s’ils ne sont pas aussi faciles à filtrer dans la vue des résultats de la recherche globale.
Pour concevoir une recherche globale complexe, essayez la recherche avancée.
Recherche contextuelle
Les recherches contextuelles sont disponibles sous certains onglets, comme Issues et Pull requests. Ces recherches se limitent au dépôt actuel et ne retournent que des résultats de ce type. L’avantage de cette délimitation est qu’elle permet à l’interface utilisateur d’exposer des filtres propres aux types connus, comme des auteurs, des étiquettes, des projets, etc.
La recherche contextuelle est l’option de prédilection quand vous recherchez quelque chose dans le dépôt actuel. Dans notre scénario, elle convient parfaitement pour trouver des résultats de recherche mentionnant « barre latérale », résultats que vous pourriez ensuite facilement affiner à l’aide des listes déroulantes de filtres.
Utilisation des filtres de recherche
Il existe un nombre infini de manières d’effectuer une recherche à l’aide de la syntaxe de recherche complète. Néanmoins, la plupart des recherches utilisent uniquement quelques filtres courants. Bien qu’ils soient souvent disponibles à partir des listes déroulantes de recherche contextuelle, il est parfois plus pratique de les taper directement.
Voici quelques exemples de requêtes de filtrage :
| Requête | Explication |
|---|---|
is:open is:issue assignee:@me |
Problèmes ouverts attribués à l’utilisateur actuel (@me) |
is:closed is:pr author:contoso |
Demandes de tirage fermées créées par @contoso |
is:pr sidebar in:comments |
Demandes de tirage où « barre latérale » est mentionné dans les commentaires |
is:open is:issue label:bug -linked:pr |
Problèmes ouverts étiquetés en tant que bogues qui n’ont pas de demande de tirage liée |
En savoir plus sur la compréhension de la syntaxe de recherche
Qu’est-ce qu’une responsabilité git ?
Une responsabilité git, ou git blame, est une commande qui affiche l’historique des commits d’un fichier. Elle vous permet de savoir qui a apporté quelles modifications et à quel moment. Il est ainsi beaucoup plus facile d’identifier les autres personnes qui ont travaillé sur un fichier pour déterminer leur contribution ou participation.
Notes
Certains systèmes Git substituent git praise à git blame pour éviter toute connotation de jugement.
Responsabilité dans GitHub
GitHub étend les fonctionnalités git blame de base avec une interface utilisateur plus robuste.
Dans notre scénario, il existe plusieurs manières d’accéder à cette vue. Vous avez peut-être trouvé du code de barre latérale dans la recherche globale et sélectionné l’option Rendre responsable pour voir qui a travaillé dessus en dernier, ou peut-être que vous avez trouvé une demande de tirage et êtes remonté jusqu’au dernier commit qui semble lié à la description du bogue. Quelle que soit la manière d’obtenir ce résultat, l’affichage de la responsabilité est un moyen efficace pour trouver un expert technique pour la tâche en cours.
Références croisées des problèmes, commits, etc.
Ce qui fait en partie l’ingéniosité de GitHub pour les projets de logiciels collaboratifs est sa prise en charge de l’association d’éléments d’information disparates. Cette association se produit en partie automatiquement, notamment quand vous créez une demande de tirage à partir d’une série de commits sur une branche. Dans d’autres cas, vous pouvez utiliser l’interface pour lier manuellement des demandes de tirage ou projets à des problèmes à l’aide d’options de liste déroulante.
Références automatiquement liées
Pour faciliter encore plus la création de références croisées pour des éléments différents dans tout votre projet, GitHub propose une syntaxe raccourcie. Par exemple, si vous laissez un commentaire comme Duplicate of #8, GitHub reconnaît que #8 est un problème et crée le lien approprié automatiquement.
GitHub lie également les commits automatiquement si vous collez les sept premiers caractères ou plus de son ID.
Dans notre scénario, ces liens peuvent s’avérer très précieux pour démarrer si une personne a pensé à laisser du contexte. Par exemple, l’état actuel de la barre latérale risque d’avoir rencontré des problèmes connus liés à une dépendance JavaScript. Si le problème avec cette dépendance a été décrit dans un autre problème qui ne mentionnait pas explicitement les mots « barre latérale », il serait difficile de le trouver. En revanche, si quelqu’un a pensé à lier le problème indiqué dans la discussion, alors cela va vous faire gagner beaucoup de temps maintenant. Gardez ce point à l’esprit la prochaine fois que vous documenterez des problèmes et des demandes de tirage.
Découvrez-en plus sur les références et URL automatiquement liées.
Inclusion des utilisateurs avec @mention
Outre la liaison des problèmes et des commits, il s’avère souvent utile d’associer d’autres personnes aux discussions. Pour cela, la méthode la plus simple consiste à utiliser une @mention. Ce type de mention avertit l’utilisateur mentionné pour qu’il puisse participer à la discussion. C’est également un bon moyen d’identifier les personnes associées aux problèmes bien après qu’ils ont été fermés.
