Revue et Git · Mis à jour le

Pull requests et merge requests

Lister, relire et merger les pull requests GitHub et les merge requests GitLab depuis le panneau Git de Soreno, avec les CLI gh et glab, en local, dans WSL ou en SSH.

Ce qu’il faut

Le panneau Git d’un projet gagne la vue Pull requests si son dépôt est sur GitHub, Merge requests s’il est sur GitLab. Elle lit le dépôt du remote upstream, ou à défaut origin. Seuls github.com et gitlab.com sont pris en charge : pour un GitHub Enterprise ou un GitLab auto-hébergé, la vue affiche « Forge non prise en charge ».

Soreno passe par la CLI de la forge, gh pour GitHub, glab pour GitLab, installée dans l’environnement du projet : sur votre ordinateur, dans la distribution WSL ou sur le serveur SSH. Il ne stocke aucun jeton : c’est la CLI qui s’authentifie.

Si la CLI n’est pas connectée, la vue affiche « Non connecté à GitHub » et le bouton Se connecter à GitHub, ou à GitLab. Il ouvre une session de terminal, Connexion GitHub, qui lance gh auth login --hostname github.com, ou glab auth login --hostname gitlab.com ; la liste se charge dès que la connexion réussit. Si la CLI manque, « gh introuvable » vous invite à l’installer dans l’environnement du projet : Soreno ne l’installe pas.

La liste des demandes

En haut de la vue, quatre filtres : Ouvertes, Les miennes, Revue demandée, pour celles dont on vous demande la revue, et Fermées / mergées. La loupe ouvre la recherche : tapez votre texte, puis Entrée. Actualiser relit la liste ; Soreno la relit aussi quand vous revenez dans l’application, si sa dernière lecture date de plus de 30 secondes.

Chaque ligne montre le titre, la date, le numéro, l’auteur, la branche source et la branche cible, puis des icônes pour les conflits, la revue et l’état de la CI ; le survol de la ligne les détaille. La demande de la branche courante passe en tête, marquée Branche courante.

Le détail d’une demande

Cliquez sur une demande : son en-tête rappelle le titre, l’état, Ouverte, Brouillon, Fermée ou Mergée, l’auteur, les branches, les reviewers et les labels. Quatre onglets suivent :

  • Description, en Markdown ;
  • Checks, chacun avec son état, Réussi, Échec, En cours, Ignoré ou Neutre ; un clic sur son nom l’ouvre dans le navigateur ;
  • Commits, avec leur auteur et leur date ;
  • Fichiers, les fichiers modifiés et leur diff.
Le panneau Git de Soreno agrandi sur la vue Pull requests d’atelier-web. À droite, cinq pull requests ouvertes, dont la #134, Faire défiler les onglets de session, en tête et marquée Branche courante. À gauche, son détail : approuvée par hugo-petit, label ux, et l’onglet Checks avec trois checks réussis et e2e (webkit) en échec, à côté du bouton Merger.
La pull request de la branche courante, en tête de liste, et ses checks.

Le diff de Fichiers est calculé en local, par Git : Soreno récupère les commits de la demande qui manquent au dépôt, sans toucher à vos branches, puis compare depuis l’ancêtre commun avec la branche cible.

Relire dans le panneau agrandi

Agrandir les outils du projet, dans l’en-tête du panneau, ou Ctrl+Maj+M (Cmd+Maj+M sur macOS) donne au panneau la place du terminal. Fichiers passe alors sur trois colonnes : le diff, la liste des fichiers modifiés et, à droite, les demandes. Le même raccourci revient au terminal, même quand le terminal a le focus ; si le panneau est fermé, il l’ouvre directement agrandi.

Le panneau Git agrandi sur l’onglet Fichiers de la pull request #134 : le diff de SessionTabs.tsx, la liste des quatre fichiers modifiés avec leurs lignes ajoutées et retirées, et les pull requests à droite.
Trois colonnes : le diff, les fichiers, les demandes.

Merger

Merger ouvre une confirmation : la branche source sera mergée dans la branche cible, puis supprimée ou conservée selon les réglages du dépôt. Choisissez la méthode : sur GitHub, Commit de merge, Squash and merge ou Rebase and merge, selon celles que le dépôt autorise ; sur GitLab, Commit de merge ou Squash and merge, selon le réglage de squash du projet. Le choix n’apparaît que s’il y a plusieurs méthodes.

Si les derniers checks ont échoué ou tournent encore, la confirmation le signale et son bouton devient Merger sans vérification. Il ne contourne pas les règles du dépôt : quand elles exigent ces checks, Merger reste grisé.

La confirmation Merger #134 : feat/onglets-defilants sera mergée dans main, la branche source sera supprimée. Un avertissement signale que les derniers checks ont échoué ; Squash and merge est choisi, à côté de Commit de merge et Rebase and merge, et le bouton de confirmation devient Merger sans vérification.
Des checks en échec : Soreno prévient avant de merger.

Tant que la demande est bloquée, Merger reste grisé et son survol donne la raison : brouillon, conflits, checks non réussis, approbations manquantes, branche en retard sur la cible, mergeabilité en cours de calcul ou règle du dépôt.

Les autres actions

  • Marquer comme prête, sur un brouillon, le rend prêt pour la revue ;
  • Ouvrir dans le navigateur, l’icône à côté, affiche la demande sur GitHub ou GitLab ;
  • dans le menu …, Checkout dans un nouveau worktree ouvre la création d’un worktree sur la branche de la demande, ajouté à Soreno comme un projet ;
  • Checkout dans ce worktree bascule le projet sur cette branche, s’il n’a pas de modifications en cours ;
  • Fermer ferme la demande ; une demande fermée propose Rouvrir.

La branche locale reprend le nom de la branche source. Pour une demande venue d’un fork, elle s’appelle pr/ suivi du numéro sur GitHub, mr/ sur GitLab ; un push depuis cette branche part vers le dépôt de la liste, pas vers le fork.

Quand la forge ne répond pas

Si la limite de l’API est atteinte ou que le réseau manque, Soreno garde le dernier état connu et le signale. Les autres erreurs, comme Aucun remote ou Accès refusé, s’affichent à la place de la liste, avec Réessayer.