GitHub Stacked PRs

 (github.github.com/gh-stack)
10 points par GN⁺ 2026-04-14 | 2 commentaires | Partager sur WhatsApp
  • Nouvelle fonctionnalité de GitHub permettant de diviser de gros changements de code en petites PR empilées et faciles à relire, puis de les gérer de manière séquentielle
  • Chaque PR est relue indépendamment, et l’ensemble de la pile peut être fusionné en un clic
  • Via l’interface GitHub et la CLI gh stack, prise en charge de la création, navigation, rebase et fusion des piles, avec une stack map pour visualiser la hiérarchie
  • Grâce à l’intégration d’agents de codage IA, il est possible de découper automatiquement un gros diff en unités empilées ou de développer directement selon une approche basée sur les piles
  • L’objectif est de réduire la complexité et le risque de conflits liés aux grosses PR, tout en améliorant l’efficacité de la revue et la vitesse de développement des équipes

Fonctionnalités principales

  • Gestion des PR empilées

    • Plusieurs PR peuvent être organisées sous forme de pile ordonnée (stack), chaque PR étant basée sur la branche de la PR située juste en dessous
    • Cela forme au final une structure en chaîne qui aboutit à la branche principale
    • GitHub reconnaît l’ensemble de la pile et affiche une stack map dans l’interface, ce qui permet aux reviewers de naviguer facilement entre les niveaux
    • Les règles de protection de branche s’appliquent à la branche cible finale, et les tests CI s’exécutent sur toutes les PR de la pile

  • Gestion simplifiée des piles

    • Depuis l’interface GitHub, il est possible de naviguer entre les PR d’une pile, de vérifier l’état de chaque niveau et d’exécuter un cascading rebase sur l’ensemble de la pile
    • Toute la pile peut être fusionnée en un clic, ou seulement une partie
    • Après la fusion, les PR restantes sont automatiquement rebasées, de sorte que la PR non fusionnée la plus basse soit réajustée pour cibler la branche par défaut

  • Prise en charge CLI avancée

    • Avec la CLI gh stack, il est possible d’effectuer dans le terminal la création de piles, le rebase, le push des branches, la création de PR et la navigation entre les niveaux
    • Exemples de commandes CLI
      • gh extension install github/gh-stack : installer l’extension
      • gh stack alias : configurer une commande abrégée
      • gs init <branch> : créer la première branche
      • gs add <branch> : ajouter un nouveau niveau
      • gs push : pousser toutes les branches
      • gs submit : créer les PR de toute la pile

  • Intégration des agents IA

    • La commande npx skills add github/gh-stack permet à un agent de codage IA d’être configuré pour effectuer des opérations sur les piles
    • Il peut automatiquement découper un gros diff en unités empilées, ou mener un développement basé sur des piles dès le départ

Pourquoi les PR empilées sont nécessaires

  • Les grosses PR entraînent une hausse de la difficulté de revue, des retards de fusion et un risque accru de conflits
    • Les reviewers perdent le contexte, la qualité des retours baisse et le rythme de toute l’équipe ralentit
  • Les Stacked PRs répondent à ce problème en fractionnant les changements en une chaîne de PR petites et ciblées
    • Chaque PR peut être relue indépendamment, tandis que l’ensemble des changements s’accumule de façon séquentielle

Pour commencer

À lire aussi

2 commentaires

 
tested 6 시간 전

Stacked PRs est actuellement en aperçu privé. Cette fonctionnalité ne fonctionnera pas à moins d’être activée pour votre dépôt.
 
GN⁺ 2026-04-14
Avis sur Hacker News

  • Ce qu’il me faut, ce n’est pas des « stacked PR », mais une interface de gestion des commits unitaires

    • Je veux pouvoir fusionner seulement certains commits de manière indépendante, ou marquer un commit précis comme relu
    • Je voudrais faire du interactive rebase/squash/edit au niveau du commit, mais c’est impossible dans l’interface de GitHub
    • Il faut aussi une fonctionnalité pour commenter les messages de commit ou des commits précis, ainsi qu’une visualisation des changements entre force-push via un diff of diff
      Git a déjà la notion de commit, donc je ne vois pas pourquoi on ajoute encore par-dessus une abstraction appelée « stacked PR »
    • C’est un concept qui reprend dans GitHub le workflow de stacked diff créé par Phabricator
      Cela facilite le démarrage d’un nouveau travail sur une base qui n’a pas encore été fusionnée, et permet aux reviewers de relire séparément de petits morceaux d’un gros changement
      C’était particulièrement utile dans les gros monorepos ou les environnements d’entreprise
    • Mais j’ai le sentiment que réécrire en permanence l’historique git est risqué
      Répéter squash, rebase et force push, c’est comme se tirer une balle dans le pied
      git merge --no-ff, git log --first-parent, git bisect --first-parent suffisent aussi à obtenir le même effet
    • SuperSmartLog(SSL), utilisé chez Meta, était la meilleure implémentation
      C’est publié dans la documentation interactive smartlog et il existe aussi une extension VSCode
      C’est dommage que cela ne se soit pas davantage répandu
    • Le workflow que je préfère consiste à considérer les PR/MR comme des « changements atomiques »
      Les commits servent alors à représenter le processus d’évolution qui mène à cette PR
      1. Si la PR est trop grosse, je la découpe en commits
      2. J’enregistre dans les commits l’évolution de la PR (y compris les raisons, comme « remplacer foo par bar »)
    • Ce que tu décris, c’est en fait Gerrit

  • Après avoir utilisé Phabricator et Mercurial puis être revenu à GitHub, j’ai eu l’impression de retourner à l’âge de pierre
    Je suis donc content de voir jujutsu ou cette nouvelle fonctionnalité réintroduire le flux stacked diff
    Ce n’est pas utile seulement pour les monorepos, mais aussi pour le développement de fonctionnalités au long cours, car cela permet de garder des revues petites et rapides

    • Heureusement que Git a gagné la guerre des DVCS
      Mercurial disait toujours être « plus rapide que git », mais en pratique il était plus lent ou cassait
      Git est moche, mais rapide et fiable
    • Je n’aime toujours pas les revues GitHub, donc j’utilise Gerrit
      Quand il faut relire de gros changements (par exemple une mise à jour de dépendances vendor), l’expérience de revue fichier par fichier de GitHub n’est pas terrible
    • L’interface de revue de Phabricator me manque énormément

  • Enfin !
    Je n’ai jamais compris le modèle de GitHub où « PR = branche »
    Les stacked commits à la Phabricator/Gerrit correspondent bien mieux à ma manière de penser
    Il ne me reste plus qu’à installer la CLI

    • Dommage de dépendre de GH CLI, mais j’espère qu’il y aura une prise en charge dans l’interface au moment de la disponibilité générale
    • Dans mon modèle mental, j’ai du mal à voir la différence entre une branche et une stacked PR
      Une branche, ce n’est qu’un drapeau planté sur un commit, et laisser plusieurs points de repère n’a de sens que si les parties précédentes peuvent être fusionnées indépendamment

  • Je me demande si cela résout enfin le problème d’UX de Squash & Merge
    Moi, j’empile manuellement main <- PR A <- PR B <- PR C,
    et si la PR A est fusionnée en premier, la PR B devient un enfer de conflits
    L’interface de GitHub change automatiquement la branche cible vers main et cela crée des conflits bizarres
    J’ai juste besoin d’un outil « qui marche, tout simplement »

    • Les conflits viennent probablement du fait que la PR A a été fusionnée en squash
      J’espère que gh stack sync les résout avec rebase --onto
    • En pratique, la CLI et le serveur gèrent cela avec git rebase --onto
      Exemple : PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      Si PR1 et PR2 sont fusionnées en squash, main devient S1(A+B), S2(C+D)
      Ensuite, git rebase --onto S2 D branch3 permet de remettre tout cela en ordre sans conflit
    • Dans mon workflow, si A est fusionné, alors B devrait déjà l’être aussi
      On peut résoudre ça avec git rebase --update-refs --onto origin/main A C
      La GH CLI automatise ce processus
    • Ce problème est une limite logique de git, pas un bug
    • Je suis d’accord : c’est agaçant et peu intuitif
      Mais au final, la seule solution reste de réorganiser les commits avec un rebase manuel

  • Quand on développe seul, on a rarement besoin de stacked PR, mais l’habitude de découper en petites unités reste importante
    Comme les outils d’IA (par ex. Claude Code) ont tendance à produire de gros diffs d’un coup,
    ce serait intéressant que les agents sachent eux-mêmes découper le travail en unités logiques

    • Une PR peut déjà contenir plusieurs commits, donc si un agent ne sait pas bien les parcourir, les stacked PR n’aideront pas davantage
    • J’utilise Claude avec jj pour lui faire recomposer une pile de travail de manière favorable à la revue au-dessus du trunk
    • Si on crée de petites branches dépendantes les unes des autres, cela conduit à un enfer de synchronisation quand une branche précédente est mise à jour
    • Un guide d’intégration d’agent lié au sujet est disponible sur la page web

  • git-spice mérite aussi un coup d’œil
    C’est compatible avec GitLab et d’autres, et chez moi il remplace entièrement les commandes git classiques

  • C’est cool que GitHub ait enfin ajouté une fonction de stack à l’interface
    C’est similaire à glab stack de GitLab
    En revanche, le processus de fusion risque d’être un peu maladroit : si on fusionne le bas de la pile, le reste est rebasé et la CI repart de zéro
    Si je veux fusionner seulement les deux patchs du bas sur trois, je dois attendre les tests pour chacun

    • Dans la conception actuelle, si la CI des deux PR du bas passe, elles peuvent être fusionnées d’un coup
      Ensuite, le haut de la pile est rebasé et la CI peut repartir
      Cette partie sera ajoutée plus clairement à la documentation

  • Je ne vois pas très bien la nécessité des stacked PR
    Avec git, on peut déjà relire et appliquer des patchsets individuellement
    Le modèle PR a plutôt tendance à tout regrouper en un seul bloc
    Les stacked PR ressemblent à une nouvelle abstraction pour contourner ce problème

    • Dans l’équipe où j’ai travaillé, une PR était considérée comme « la plus petite unité applicable »
      Les commits internes ne sont qu’un historique de développement, et à la fusion on les squashe en un seul
      Cela permet d’empiler librement des commits pendant le développement, puis de ne garder qu’un changement propre à la fusion
    • Dans Phabricator, la relation 1:1 entre commit et diff était beaucoup plus naturelle
      L’implémentation de GitHub donne un peu l’impression d’une fonctionnalité collée à la va-vite
    • Une PR est à l’origine une unité de changement atomique, et les stacked PR permettent de travailler sur une nouvelle PR basée sur celle-ci
      Autrement dit, c’est une structure qui empile progressivement le travail en unités relisibles

  • Une startup appelée Graphite se concentre déjà sur les stacked PR
    J’utilise Graphite depuis un moment, donc je suis content de voir GitHub implémenter quelque chose de similaire

    • Dans mon entreprise aussi, on utilise Graphite avec satisfaction

  • J’aime les stacked PR, mais cette implémentation de GitHub me semble étrange
    Il suffirait que chaque branche pointe vers son parent
    Plus que la CLI, c’est surtout une prise en charge dans l’interface qu’il faudrait

    • Mais après la fusion de la branche parente, le rebase devient pénible
      Ce serait bien que la CLI automatise cela
    • La CLI est optionnelle, et on peut aussi créer des stacked PR depuis l’interface
      Si on met en place une chaîne de branches, c’est pour que le diff n’affiche que les changements de la branche concernée
    • En réalité, c’était déjà possible dans git d’origine
      Ce qui manquait surtout, c’était l’interface et la visualisation
    • J’espère que l’étape suivante apportera des améliorations de l’interface