Trouver le changement à l'origine d'un problème

Partez de ce que vous connaissez : un message de commit, un fichier, une ligne supprimée ou une version qui fonctionnait. Riff propose un parcours pour chaque indice et affiche la portée de la recherche pendant l'investigation.

Lire le graphe et rechercher dans le journal

Suivez les noms des branches et des tags dans le graphe des commits, ou affichez toutes les branches pour voir où leurs historiques se rejoignent. Sélectionnez un commit pour consulter son auteur, ses parents, son titre, son corps et ses fichiers modifiés. Le filtre du journal recherche parmi les commits chargés par titre, auteur ou SHA. La recherche approfondie utilise un index distinct sur l'ordinateur avec jusqu'à 1 000 commits récents, y compris le texte des messages, et renvoie jusqu'à 500 occurrences. Elle ne garantit pas une recherche dans tout l'historique.

Naviguer avec la recherche unifiée

Ouvrez la palette de commandes pour trouver des actions disponibles, des dépôts enregistrés, des branches locales et distantes et des commits du dépôt actif. Filtrez par type de résultat et combinez des mots du message, de l'auteur ou du SHA.

Ouvrir une branche ou un commit dans les résultats affiche son historique sans effectuer de checkout. La recherche de commits exige au moins deux caractères et couvre les 1 000 commits les plus récents parmi les références du dépôt actif. Chaque type affiche jusqu'à 20 résultats ; précisez la requête lorsque la limite est atteinte. Elle ne parcourt pas tous les fichiers ni l'historique complet de tous les dépôts.

Suivre l'historique d'un fichier

Ouvrez l'explorateur d'historique du dépôt actif et choisissez le fichier. Son historique suit les renommages et charge 50 commits à la fois.
Sélectionnez une révision et examinez ses changements. Utilisez blame pour identifier le commit responsable d'une ligne, puis ouvrez ce commit ou la version précédente.
Comparez deux révisions pour voir les différences entre fichiers. Riff résout les révisions en commits précis avant de charger la comparaison.
Utilisez Retour pour retrouver l'investigation précédente, avec les pages chargées, le commit sélectionné et la position dans blame.

Le sélecteur affiche jusqu'à 10 000 chemins. Blame refuse les fichiers de plus de 1 Mio, comportant plus de 10 000 sauts de ligne ou des lignes de plus de 20 000 caractères. Les comparaisons sont limitées à 4 Mio pour le total des blobs modifiés et pour le patch généré ; une petite modification de gros fichiers peut donc dépasser cette limite. Un contenu non pris en charge reçoit un état explicite.

Rechercher du texte ajouté ou supprimé

Dans l'explorateur d'historique, saisissez du texte littéral et choisissez un filtre de chemin ou de dossier, la sensibilité à la casse et une révision ou toutes les références. Suivez le nombre de commits examinés et les résultats pendant la recherche. Ouvrez une occurrence pour examiner le changement.

La recherche examine les lignes ajoutées et supprimées en comparant chaque commit à son premier parent. Elle ne parcourt pas séparément tous les parents d'une fusion. Elle s'arrête à 2 000 commits ou 1 000 occurrences ; les contenus ignorés et les limites atteintes signalent une recherche incomplète. Son cache reste en mémoire, sans créer d'index permanent de tout le dépôt.

Pour du texte dans les fichiers de travail actuels, utilisez la recherche dans les fichiers. Elle accepte la sensibilité à la casse, les mots entiers, les expressions régulières et, au choix, les fichiers non suivis. Les résultats sont regroupés par chemin et s'ouvrent dans l'éditeur par défaut.

Localiser une régression avec Bisect

Ouvrez Bisect dans le dépôt. Indiquez une révision qui fonctionnait et une révision défaillante, puis vérifiez les commits exacts avant de commencer.
Préparez un arbre de travail propre. Des changements en attente, une autre opération Git ou des collisions avec des fichiers ignorés peuvent empêcher le changement de révision. Déplacez vous-même les fichiers ignorés qui bloquent l'opération ; ce ne sont pas des données jetables.
Démarrez l'investigation. Riff enregistre un point de récupération et prépare un candidat. Exécutez la vérification appropriée, puis marquez la révision comme fonctionnelle, défaillante ou impossible à tester.
Répétez pour le candidat suivant. Le dialogue montre les résultats enregistrés, les candidats restants et la destination de retour. Des commits ignorés peuvent laisser plusieurs causes possibles.
Terminez l'investigation pour revenir à la branche ou au commit initial. Fermer uniquement le dialogue conserve la session ; utilisez le bandeau du dépôt pour reprendre, y compris après un redémarrage de Riff.

Bisect n'exécute pas de commandes de test arbitraires à votre place. L'intervalle est limité à 100 000 commits et la liste affichée à 100 candidats. Les sessions Git existantes utilisant des termes personnalisés, des filtres de chemin ou le mode first-parent peuvent être inspectées et terminées, mais ne sont pas réinterprétées par le parcours guidé.

Préparez le correctif dans un commit ciblé ou vérifiez les points de récupération avant de modifier l'historique.