Comparer commits et branches avant une revue

Avant la revue, décidez de la question. « Qu’a modifié ce commit ? » et « Qu’a changé cette branche depuis sa divergence ? » peuvent produire des diffs différents, même avec les mêmes noms de branches.

Vous cherchez une app Mac pour lire les changements validés ? Consultez le fonctionnement et les limites du lecteur de diff Git de Yenpo avant les étapes ci-dessous.

Ouvrir une comparaison

Pour examiner une branche feature par rapport à main, suivez ces étapes en remplaçant les noms d’exemple par vos branches :

Ouvrez le dépôt Git local et cliquez sur Comparer les versions… dans la barre latérale.
Passez de Commit à Comparer.
Dans De (base), sélectionnez Branches locales puis main. Dans À (head), sélectionnez Branches locales puis feature. Chaque colonne a sa propre source de branches et son champ de recherche.
Choisissez Depuis la divergence des branches pour le travail sur feature, ou Comparaison directe pour comparer les deux extrémités. La section suivante explique la différence.
Vérifiez les noms de branches et identifiants courts dans le résumé. Si le sens est incorrect, resélectionnez les branches dans De et À, puis cliquez sur Voir les modifications.
Sélectionnez un fichier dans l’arbre des fichiers modifiés pour lire son diff intégré.

Pour utiliser origin/main, choisissez Branches distantes dans la colonne De. Ce sont les références de suivi déjà stockées localement, pas une vue du serveur en direct. Pour des commits distants plus récents, mettez le dépôt à jour avec votre client Git habituel puis rouvrez le sélecteur.

Yenpo fige la comparaison sur des commits précis. Si une branche évolue, la revue reste sur les commits choisis. Ouvrez une nouvelle comparaison pour examiner la nouvelle extrémité.

Choisir un mode

Question	Mode	Compare
Qu’a modifié un commit ?	Commit	Premier parent → ce commit ; commit racine comparé à un arbre vide
En quoi diffèrent actuellement deux extrémités de branches ?	Comparaison directe	Extrémité base → extrémité head
Qu’a changé head depuis la divergence ?	Depuis la divergence des branches	Base de fusion → extrémité head

Prenons cet historique :

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

Une comparaison directe de main → feature compare M2 à F2 et inclut donc le travail des deux côtés. Depuis la divergence des branches compare X à F2, généralement adapté à « Qu’a ajouté feature ? ». Cela ne simule pas la fusion finale et ne prédit pas ses conflits.

Pour un commit de fusion, le mode Commit compare uniquement au premier parent. C’est une vue de la fusion, pas un diff avec chaque parent : assurez-vous qu’elle répond à votre question.

Vérifier la paire exacte de révisions

Survolez la ligne de révision au-dessus de l’arbre pour voir les identifiants complets. En Comparaison directe, ce sont les commits De et À sélectionnés. En Depuis la divergence des branches, la base est nommée merge-base(...) et son identifiant est l’ancêtre commun, pas l’extrémité de la branche De.

Pour vérifier ces mêmes versions dans Git, lancez ces commandes en lecture seule depuis le dépôt. Remplacez BASE_COMMIT_OID et HEAD_COMMIT_OID par les deux identifiants complets affichés dans Yenpo :

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

La première commande identifie les deux commits ; la seconde résume les différences entre leurs arbres validés. Les fichiers non validés sont exclus. Pour une ancienne revue, utilisez les identifiants notés : les noms de branches peuvent désormais pointer vers des commits plus récents.

Lire le diff dans son contexte

L’arbre ouvre des diffs intégrés en lecture seule. Les fichiers de comparaison peuvent côtoyer les actuels : vérifiez la version de chaque onglet avant de raisonner sur un appelant ou un test. L’arbre de travail peut déjà contenir des changements absents du head choisi.

Pour chaque changement de comportement, lisez au-delà des lignes modifiées :

Trouvez un appelant pouvant atteindre le nouveau code.
Déterminez l’entrée ou l’état qui le déclenche.
Suivez la valeur de retour, l’erreur ou l’effet de bord jusqu’à l’appelant.
Vérifiez qu’un test existant atteint réellement cet état.

Un test nommé « handles concurrent reads » peut simplement effectuer deux appels successifs. Lisez sa préparation et ses assertions, pas seulement son nom. La revue du cache de promesses le montre en pratique.

Demander une revue à l’AI Reader

Utilisez Demander à l’IA d’examiner cette comparaison dans l’en-tête. Le bouton prépare un brouillon avec la comparaison jointe, sans encore envoyer la requête. Vérifiez la pastille, précisez ce qui doit être examiné et envoyez quand vous êtes prêt. Sans modèle connecté, suivez d’abord Connecter un fournisseur de modèles.

Par exemple :

Examine cette modification pour les régressions d’annulation et de gestion d’erreurs. Pour chaque constat, donne l’emplacement modifié, l’état déclencheur, ce que verrait l’utilisateur et le code qui l’étaye. Liste séparément les problèmes déjà présents dans la base.

Vérifiez que chaque déclencheur proposé peut réellement se produire dans les commits choisis. Si l’ordre reste flou, demandez une reproduction ou un test ciblé, puis lancez-le vous-même. Un test présent dans une réponse n’a pas été exécuté.

Quand vous voulez corriger quelque chose

Les comparaisons Git restent toujours en lecture seule. Pour corriger, démarrez une discussion ordinaire sur l’arbre de travail actuel et activez Autoriser les modifications. Gardez la comparaison comme référence.

Ensuite, lisez le diff de l’arbre de travail et lancez vous-même les vérifications du projet. Arrêter ne restaure pas les fichiers déjà écrits. Si d’autres changements existaient, distinguez-les du correctif avant de choisir quoi valider.