Les Stacked PR de GitHub entrent en préversion publique

 (github.blog)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Les stacked pull requests, qui découpent les grands changements en couches plus petites et faciles à relire, sont déployées progressivement en préversion publique sur tous les dépôts
  • Chaque PR cible la couche située juste en dessous, ce qui permet aux membres de l’équipe de relire indépendamment et en parallèle des diffs au périmètre réduit
  • Lorsqu’on fusionne la PR la plus récente, les couches non fusionnées situées en dessous sont intégrées en une seule fois ; si seule une partie est fusionnée, les PR au-dessus sont rebasées automatiquement et leur cible est modifiée
  • Les processus existants de revue de PR, les vérifications obligatoires, la protection des branches et les exigences de fusion continuent de s’appliquer, et les stacks peuvent être gérées depuis GitHub.com, la CLI, l’app mobile et GitHub Copilot
  • La préversion publique sera étendue à l’ensemble des dépôts sur plusieurs jours, et la prise en charge de la Merge queue sera proposée progressivement au cours des semaines suivantes

Une structure de PR qui empile de petits changements

  • Les grands changements sont divisés en plusieurs PR petites et ciblées, organisées en couches de changements ordonnées
  • Après avoir créé une branche et une PR pour le premier changement, on ajoute par-dessus d’autres branches et PR, chaque PR ciblant la couche immédiatement inférieure
  • Cela réduit la gêne liée à la revue d’une seule très grosse PR ou à la nécessité de rebaser manuellement plusieurs branches en continu
  • L’équipe Next.js estime que cela a facilité les revues de PR en lui permettant de garder les changements individuels petits tout en livrant de grandes fonctionnalités

Création de stacks et environnement de travail

  • L’extension CLI s’installe avec la commande suivante
gh extension install github/gh-stack
  • Les stacks peuvent être créées et gérées depuis GitHub.com, GitHub CLI et l’application mobile GitHub
  • Dans les agents de codage comme GitHub Copilot, la skill gh-stack peut être utilisée

Revue indépendante par couche

  • En ouvrant une PR dans une stack, il est possible de relire uniquement le diff de cette couche, et non l’ensemble des changements
  • La carte de la stack en haut de la PR permet de voir où se situe le changement courant dans l’ensemble du travail
  • Les membres de l’équipe peuvent relire différentes couches en parallèle, ce qui évite que les travaux suivants soient bloqués jusqu’à la fin de la revue
  • Les règles existantes de protection des branches peuvent être combinées avec la revue par couche afin de contrôler la qualité à chaque étape
  • TED indique qu’après l’adoption de l’IA, la hausse de productivité des développeurs a entraîné des PR plus volumineuses, devenues un goulet d’étranglement pour les revues ; le découpage des changements en petites unités logiques, dans l’ordre des dépendances, a amélioré la vitesse et la précision des revues

Fusion de tout ou partie d’une stack

  • Fusionner la PR la plus récente une fois qu’elle est prête intègre en une seule fois cette PR et toutes les couches non fusionnées situées en dessous
  • Il est aussi possible de fusionner d’abord seulement une partie de la stack, en sélectionnant une ou plusieurs couches inférieures
    • Les PR situées au-dessus restent ouvertes
    • Elles sont automatiquement rebasées en fonction des changements fusionnés, et leur branche cible est également modifiée
  • La protection des branches, les vérifications obligatoires et les exigences de fusion existantes continuent de s’appliquer afin de contrôler les changements qui arrivent dans main
  • Il est possible de fusionner sélectivement non seulement toute la stack, mais aussi une seule couche ou certaines couches seulement

Préversion publique et calendrier de prise en charge

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Commentaires sur Hacker News

  • J’ai utilisé la preview pendant un moment, et je suis surpris qu’ils élargissent le déploiement alors qu’il reste beaucoup de problèmes non résolus
    Par exemple, la fusion de toute la pile casse complètement dans plusieurs cas : https://github.com/github/gh-stack/discussions/212
    On peut fusionner PR par PR, mais si on utilise à la fois le squash merge et les revues obligatoires, il faut redemander une approbation pour chaque PR de la pile, ce qui fait perdre le principal avantage des PR empilées
    gh stack réduit un peu le travail manuel, mais il faut quand même bien comprendre git rebase. Si la branche locale n’est pas synchronisée avec le remote, le gh stack rebase proposé par l’UI échoue aussi, et l’outil n’explique pas pourquoi
    En revanche, j’aime bien l’UI des piles : elle reste simple tout en montrant suffisamment les relations entre PR. En partant du principe qu’on a déjà une raison d’empiler des PR, c’est surtout un outil qui rend le workflow plus confortable, pas qui apporte une nouvelle capacité

    • Des correctifs sont en cours de déploiement progressivement pour résoudre les problèmes de squash merge
      Le CPRMC interne (Create Pull Request Merge Commit) détermine si une PR est prête à être fusionnée en vérifiant aussi bien la présence de conflits que la correspondance entre les approbations et le commit qui sera réellement créé
      Pour faire un squash merge de plusieurs PR, il faut calculer une suite de commits squash puis les rattacher à nouveau aux règles et aux revues. C’est relativement simple pour la première PR, mais à partir de la deuxième, les commits ancêtres ont été squashés et n’existent plus tels quels dans la branche, ce qui complique les choses ; et quand il y a plusieurs parents, c’est encore bien plus difficile
      Actuellement, 99 % des fusions de piles réussissent, mais augmenter nettement ce taux est la priorité absolue de l’équipe
    • Aujourd’hui, j’ai supprimé la branche pointée par une PR empilée, et j’ai rencontré un bug où elle reste bloquée en état merging sans indication supplémentaire
      J’ai même vérifié la page de statut de GitHub en pensant à une panne partielle du système de PR, mais c’était en fait un bug propre à la fonctionnalité de PR empilées
    • Depuis 2021, on dirait que tout le secteur est passé à fond à une logique de prêt, feu, visez
    • Dans mon entreprise aussi, on a eu récemment énormément de problèmes avec cette fonctionnalité et la merge queue

  • L’équipe GitHub Stacked PRs l’ouvre désormais plus largement pour que tout le monde puisse créer des piles : https://gh.io/stacks
    Ils recherchent surtout des retours sur l’UI et la CLI, et préparent aussi beaucoup de mises à jour pour améliorer l’expérience d’utilisation des PR
    C’est l’un des plus gros lancements de l’histoire de GitHub, couvrant presque tous les services, des Actions et règles de protection jusqu’à la CLI et à l’app mobile ; ils peuvent donc aussi répondre aux questions sur les choix de conception et le fonctionnement interne

    • Premier essai aujourd’hui, et j’aime bien le résultat
      On utilise déjà une UI locale maison pour voir les dépendances de PR empilées sous forme d’arbre et suivre l’état des revues et de la CI de chaque PR, donc j’aimerais bien avoir un arbre et des indicateurs d’état aussi dans l’UI web de GitHub
      L’UI web ne semble pas permettre de fusionner uniquement la PR du bas de la pile, mais comme ça peut partager le code et le workflow existants, j’aimerais bien que ça arrive aussi dans l’outil natif de GitHub
    • Je me demande si le support des PR empilées à travers des forks est prévu prochainement
      Ça semble être une fonctionnalité importante pour que ce soit utile sur les dépôts publics, donc je suis surpris qu’elle n’ait pas été livrée avant la preview publique
    • C’est exactement la fonctionnalité qui me manquait le plus de Gerrit
    • Je me demande pourquoi vous avez choisi la PR supplémentaire comme unité de découpage du travail
      Au lieu d’une vraie UI permettant de revoir, appliquer et corriger commit par commit, est-ce qu’il y avait une réflexion particulière derrière le choix de facto d’un « lot de lots de patchs », en ignorant le workflow de série de patchs des mailing lists, qui est pourtant l’origine de cette approche ?

  • C’est l’un des plus gros changements apportés à GitHub depuis des années
    Avec l’arrivée d’un workflow empilé sur l’une des plus grandes plateformes d’hébergement de code au monde, beaucoup de développeurs pourraient découvrir une manière de travailler dont ils ignoraient jusqu’à l’existence
    Si l’idée que les piles produisent de meilleurs logiciels est juste, cela pourrait réellement aider beaucoup de développeurs

  • Je me demande quel est l’avantage de ces PR empilées par rapport à une revue de commits bien organisés, commit par commit
    Un problème encore plus important est que les grosses PR générées par l’IA demandent un mode de revue distinct. La simple séquence d’affichage des diffs — par exemple définition de fonction, appels, puis tests — change énormément leur lisibilité
    Comme la programmation littéraire entremêle code et prose, il nous faudrait peut-être des diffs littéraires ou des PR littéraires mêlant différences et explications, mais je n’ai pas encore trouvé d’outil comparable

    • Pour les gens qui utilisent des diffs empilés dans Phabricator et ailleurs, c’est précisément une manière de revoir des commits bien organisés un par un
      Comme l’unité de revue — PR ou diff — reste un changement limité, la discussion se concentre sur ce changement, et même si la fonctionnalité grossit, la PR elle-même ne devient pas énorme
      On peut aussi confier chaque partie de la pile à des destinataires différents. En répartissant les reviewers entre équipe externe, collègues de la même équipe ou équipe consommatrice du changement, chacun sait clairement ce qu’il approuve
      Ce serait encore mieux si la revue GitHub introduisait des change ID pour conserver les commentaires après un rebase
    • Si on ajoute un commit à la première PR de la pile, on peut l’insérer au milieu de l’ordre global des commits
      Le fait de devoir ensuite rebaser et corriger les PR suivantes revient à corriger les commits ultérieurs d’une énorme PR unique, mais au lieu d’ajouter au hasard des commits temporaires de correction sur l’ensemble du changement, il devient plus facile de garder ensemble les commits du changement de base
      Les discussions sur ce changement de base restent aussi regroupées au même endroit, et le fait de présenter toute la pile à l’avance permet aux reviewers de comprendre la direction finale pendant que le travail continue de façon asynchrone
    • Le point clé, c’est qu’en pratique, peu de gens produisent vraiment des commits « bien organisés »
      Ils utilisent les commits comme des points de sauvegarde, avec des messages du genre fix bug ou do work, puis ne les nettoient pas avec git rebase -i, donc si on n’active pas le squash merge obligatoire, l’historique se remplit de commits poubelles
      Pour ces développeurs, la PR tient lieu de commit, et les PR empilées leur permettent enfin d’utiliser une structure proche de plusieurs commits formant un seul changement
    • Avec les piles, on peut continuer un long travail de modification tout en produisant en permanence des diffs d’une taille raisonnable pour la revue
      Les diffs fusionnés peuvent être rebasés sur le HEAD courant et, dans les équipes qui prennent cela en charge, on ne gère généralement pas les branches directement : on travaille sur le trunk et on rebase à chaque nouveau changement
    • Dans une PR, on ne peut pas fusionner les commits un par un, mais avec une pile, si
      Si les 4 premières parties d’une fonctionnalité sont prêtes et qu’il y a un problème dans la cinquième, il n’est pas nécessaire de tout bloquer

  • Je me demande quand les PR dépendantes formant une structure en arbre plutôt qu’un historique linéaire seront prises en charge
    Chez Google, ce cas était fréquent quand on utilisait des changements empilés, et avec la hausse des agents de codage parallèles, cela risque d’être encore plus courant

    • C’est déjà une structure difficile à gérer pour les humains, donc je me demande s’il est vraiment souhaitable que les logiciels et l’IA associée encouragent ce mode de fonctionnement

  • Je me demande si le bouton de changement de menu est un emoji pile de pancakes (U+1F95E) à cause de la fonctionnalité de stack
    La formulation humoristique en soi ne me dérange pas, mais c’était une UI qui suscitait un fort doute sur ce que j’étais en train de regarder

  • J’utilisais le CLI gh stack depuis que j’en avais entendu parler, et l’outil lui-même est très bon, mais la web UI à laquelle j’ai eu accès après approbation de la preview m’a beaucoup déçu
    Même avant l’approbation, le CLI facilitait l’automatisation pour découper le travail en plusieurs PR atomiques, mais après un push elles apparaissaient comme des PR indépendantes, sans lien entre elles
    Après approbation, c’est presque pareil : la seule différence est qu’un petit menu déroulant de navigation en haut affiche les autres PR de la même stack, donc il n’y a pas de changement d’UI significatif
    On peut exécuter depuis ce menu déroulant une partie des fonctions du CLI, mais cela ressemble davantage à une commodité annexe, comme l’édition de fichiers sur le web, et dans le vrai flux de développement, le CLI ou un plugin d’IDE restera central
    Je me demande pourquoi une UI optionnelle aussi limitée a retardé si longtemps la disponibilité générale, alors que le CLI de stack était déjà en disponibilité générale dès son annonce

    • Il fallait commencer avec un minimum de fonctionnalités, mais une refonte bien plus large de l’UI des PR est en cours
      Elle devrait inclure un affichage gardant la stack visible en permanence, avec la possibilité de naviguer entre les niveaux sans multiplier les clics

  • Ce que j’aime avec jujutsu, c’est que quand on met à jour une branche, les autres branches qui en dérivent sont automatiquement rebasées
    Quand je découpe souvent le travail pour faciliter la review, je passe à jj, et cela fonctionne bien même dans le même répertoire de travail qu’un clone créé avec Git

    • jj absorb est aussi excellent
      Il déplace les modifications vers le changement pertinent le plus proche, ce qui facilite les corrections touchant plusieurs PR

  • Après avoir utilisé Graphite, il m’a été très difficile de revenir à GitHub sans stack
    J’espère qu’avec le support de GitHub, le workflow de PR empilées se généralisera et deviendra une alternative simple aux énormes PR

    • Je recommande git-spice
      C’est un excellent open source, simple à utiliser et puissant, et Graphite m’a semblé excessivement complexe par rapport à ce qu’il apporte

  • J’ai compris que l’empilement de PR est utile dans deux cas
    D’abord, quand le travail s’étend à plusieurs dépôts liés et ne peut pas être réuni dans une seule PR ; ensuite, quand on empile des PR de suivi sur la même branche pendant que la première PR est en review afin de pipeline le travail
    Mais cette fonctionnalité ne semble répondre à aucun des deux cas, et ressemble plutôt à une autre manière d’empiler des commits dans une seule PR
    En général, on peut faire des commits atomiques et significatifs, puis construire par rebase un enchaînement facile à comprendre pour le reviewer, qui peut aussi examiner commit par commit s’il le souhaite
    Je me demande quel est l’avantage spécifique qui m’échappe dans cette approche