Skip to main content
Lorsqu’une tâche est trop volumineuse pour être relue confortablement dans une seule PR, Devin peut la diviser en une pile : une série ordonnée de pull requests qui forment un même travail et sont fusionnées ensemble, de bas en haut. Chaque PR de la pile est une PR classique, ciblée, qui s’appuie sur celle qui la précède ; les relecteurs examinent ainsi une petite modification autonome à la fois, plutôt qu’un unique diff monolithique. Les piles de Devin reposent sur les pull requests empilées natives de GitHub : une pile est donc un objet GitHub à part entière, et non une convention basée sur le nommage des branches.
Les PR empilées sont prises en charge uniquement pour les dépôts GitHub.com. GitHub Enterprise Server, GitLab et les autres fournisseurs ne disposent pas d’une API de PR empilées.

Fonctionnement d’une pile

Une pile est une série de correctifs :
  • Les PR sont ordonnées de bas en haut. La PR du bas cible votre branche principale (par exemple, main) ; la branche de base de chaque autre PR est la branche de tête de la PR située juste en dessous.
  • Comme chaque PR est comparée à la couche inférieure, elle n’affiche que ses propres modifications — aucune modification des couches supérieures ou inférieures ne s’y retrouve.
  • La pile est intégrée de bas en haut. La fusion d’une PR de la pile fusionne également, de manière atomique et en une seule opération, toutes les PR ouvertes situées en dessous. À mesure que les PR inférieures sont fusionnées, GitHub redirige automatiquement les PR restantes vers la branche principale.

Quand Devin crée une pile

Devin crée des piles de manière réfléchie, jamais par opportunisme. Il ne crée une pile que lorsqu’il a délibérément décomposé une tâche en une série ordonnée de PR destinées à être intégrées ensemble — par exemple, une modification du schéma, suivie de la couche de service qui l’utilise, puis de l’interface utilisateur par-dessus. Les PR qui sont simplement basées sur la branche d’une autre PR ne sont pas regroupées dans une pile. Lorsqu’il planifie une pile, Devin :
  1. Annonce la pile par son nom avant de créer la moindre PR, afin que vous puissiez voir la série prendre forme dans votre session.
  2. Crée chaque PR comme une PR classique et ciblée — avec sa propre description et sa propre CI — chacune ciblant la branche de tête de la PR située juste en dessous.
  3. Regroupe les PR dans une pile sur GitHub une fois qu’elles ont été créées.
Chaque couche répond aux mêmes exigences que toute PR autonome livrée par Devin : un diff minimal et ciblé, ainsi qu’une description informative rédigée pour un relecteur qui n’a pas vu le code.

Maintenir la cohérence de la pile

Une pile n’est pas figée une fois créée. Devin reste associé à chaque PR de la pile pendant toute la durée de la session :
  • Résolution des conflits — Si une couche entre en conflit de fusion avec la branche située juste en dessous (par exemple, après l’intégration de retours de revue sur une couche inférieure ou lorsque la branche principale évolue sous la pile), Devin en est automatiquement informé et résout les conflits de manière transparente. Il ne vous sollicite que lorsqu’un conflit implique une décision importante nécessitant votre intervention.
  • CI sur l’ensemble de la pile — Devin surveille la CI de chaque couche et corrige les échecs au fur et à mesure, en suivant l’état de préparation de toute la série plutôt que de gérer les PR une par une.
  • Reciblage automatique — À mesure que les couches inférieures de la pile sont fusionnées, GitHub recible les PR restantes sur la branche principale. Aucun suivi manuel des rebase n’est nécessaire.

Utiliser les piles

Vous pouvez guider le comportement d’empilement de Devin au cours d’une session :
  • Demandez à Devin de scinder une modification importante en pile, ou de conserver le travail dans une seule PR.
  • Demandez à Devin d’ajouter des PR de suivi au sommet d’une pile existante.
  • Demandez à Devin de vérifier le statut d’une pile — il indique l’état de chaque couche, la CI, la décision de review et la possibilité de fusion.
  • Demandez à Devin de dissocier la pile — la pile est dissoute et ses PR non fusionnées redeviennent des PR indépendantes, sans modification de leurs branches. Les couches déjà fusionnées le restent.
Dans la vue de session, les PR appartenant à une pile indiquent leur appartenance, et les piles annoncées apparaissent avant même la création de leurs PR afin que vous puissiez suivre la progression de Devin à mesure qu’il construit la série.

Révision et fusion de piles de PR

Devin Review prend en charge les piles de PR de manière native : l’ensemble de la série est visible d’un seul coup d’œil, avec l’état de préparation de chaque couche, et la fusion s’effectue de manière atomique, de bas en haut. Pour en savoir plus, consultez la section consacrée aux PR empilées dans la documentation de Devin Review.

Limitations

  • GitHub.com uniquement — les piles ne sont pas disponibles sur GitHub Enterprise Server, GitLab, Bitbucket ni Azure DevOps.
  • Taille de la pile — une pile contient entre 2 et 100 PR.
  • Fusion — les PR empilées ne peuvent pas être fusionnées via le processus de fusion habituel de GitHub ; elles sont fusionnées via la fusion de pile, qui intègre simultanément la PR sélectionnée et toutes les PR ouvertes situées en dessous.