Stacked PRs de GitHub

 (github.github.com/gh-stack)
9 puntos por GN⁺ 16 일 전 | 1 comentarios | Compartir por WhatsApp
  • Nueva función de GitHub que permite dividir grandes cambios de código en PR pequeños y revisables para gestionarlos de forma secuencial
  • Cada PR se revisa de manera independiente, y toda la pila puede fusionarse con un solo clic
  • A través de la UI de GitHub y la CLI gh stack, ofrece soporte para crear, navegar, hacer rebase y fusionar pilas, y visualiza su estructura jerárquica con un mapa de pila
  • Mediante la integración con agentes de codificación con IA, es posible dividir automáticamente un diff grande en unidades de pila o trabajar con desarrollo basado en pilas
  • Su objetivo es reducir la complejidad y el riesgo de conflictos de los PR grandes, y mejorar la eficiencia de revisión y la velocidad de desarrollo del equipo

Funciones principales

  • Gestión de PR en pila

    • Se pueden organizar varios PR en una pila ordenada (stack), donde cada PR se basa en la rama del PR inmediatamente inferior
    • Al final, se forma una estructura en cadena que llega hasta la rama principal
    • GitHub reconoce toda la pila y muestra un mapa de pila (stack map) en la UI, para que quienes revisan puedan navegar fácilmente por cada nivel
    • Las reglas de protección de ramas se aplican a la rama de destino final, y las pruebas de CI se ejecutan para todos los PR dentro de la pila

  • Gestión simplificada de pilas

    • Desde la UI de GitHub se puede mover entre los PR de una pila, revisar el estado de cada nivel y ejecutar un rebase en cascada (cascading rebase) sobre toda la pila
    • Es posible fusionar toda la pila o solo una parte con un solo clic
    • Después de la fusión, los PR restantes se reajustan automáticamente con rebase, de modo que el PR no fusionado más inferior vuelva a apuntar a la rama base

  • Soporte sólido de CLI

    • Con la CLI gh stack se puede crear pilas, hacer rebase, hacer push de ramas, crear PR y moverse entre niveles desde la terminal
    • Ejemplos de comandos CLI
      • gh extension install github/gh-stack : instalar la extensión
      • gh stack alias : configurar comandos abreviados
      • gs init <branch> : crear la primera rama
      • gs add <branch> : agregar un nuevo nivel
      • gs push : hacer push de todas las ramas
      • gs submit : crear los PR de toda la pila

  • Integración con agentes de IA

    • Con el comando npx skills add github/gh-stack, se puede preparar a un agente de codificación con IA para que realice tareas relacionadas con pilas
    • Puede dividir automáticamente un diff grande en unidades de pila o iniciar desde cero un flujo de desarrollo basado en pilas

Por qué se necesitan los PR en pila

  • Los PR grandes provocan mayor dificultad de revisión, demoras en la fusión y riesgo de conflictos
    • Las personas revisoras pierden contexto, baja la calidad del feedback y se ralentiza la velocidad de todo el equipo
  • Stacked PRs busca resolver esto dividiendo el trabajo en una cadena de PR pequeños y enfocados
    • Cada PR puede revisarse de forma independiente, mientras que el cambio completo se acumula de manera secuencial

Cómo empezar

Lecturas relacionadas

1 comentarios

 
GN⁺ 16 일 전
Comentarios de Hacker News

  • Lo que necesito no es un "stacked PR", sino una UI para gestionar commits individuales

    • Quiero poder hacer merge de solo algunos commits de forma independiente, o marcar un commit específico como revisión completada
    • Quiero hacer interactive rebase/squash/edit a nivel de commit, pero eso no es posible en la UI de GitHub
    • Hace falta una función para comentar mensajes de commit o commits específicos, y una función para visualizar los cambios entre force pushes con diff of diff
      Git ya tiene el concepto de commit, así que no entiendo por qué poner encima otra abstracción llamada “stacked PR”
    • Es un concepto que lleva el flujo de trabajo de stacked diff que creó Phabricator a GitHub
      Facilita seguir trabajando sobre cambios que todavía no se han mergeado, y permite que los reviewers hagan revisiones independientes en unidades pequeñas de cambios grandes
      Era especialmente útil en monorepos grandes o en entornos corporativos
    • Pero a mí me parece arriesgado reescribir constantemente el historial de git
      Repetir squash, rebase y force push se siente como apuntarte al pie con una pistola
      Con git merge --no-ff, git log --first-parent, git bisect --first-parent también se puede conseguir básicamente el mismo efecto
    • SuperSmartLog(SSL), que usábamos en Meta, fue la mejor implementación
      Está publicado en la documentación de interactive smartlog y también tiene extensión para VSCode
      Es una pena que no se haya difundido más
    • El flujo de trabajo que prefiero es ver los PR/MR como “cambios atómicos”
      Los commits los uso como el proceso de evolución para completar ese PR
      1. Si el PR es demasiado grande, lo divido en commits
      2. Registro en los commits el proceso de evolución del PR (incluyendo razones como “cambié foo por bar”)
    • Lo que describes es básicamente Gerrit

  • Después de usar Phabricator y Mercurial, volver a GitHub se siente como regresar a la Edad de Piedra
    Me alegra ver jujutsu y esta nueva función recreando otra vez el flujo de stacked diff
    No solo ayuda en monorepos, también permite hacer revisiones pequeñas y rápidas en desarrollos de funcionalidades de largo plazo

    • Qué bueno que Git haya ganado la guerra de los DVCS
      Mercurial siempre decía que era “más rápido que git”, pero en la práctica era más lento o se rompía
      Git es feo, pero rápido y confiable
    • A mí todavía no me gusta el review en GitHub, así que uso Gerrit
      Al revisar cambios grandes (por ejemplo, actualizaciones de dependencias vendor), la experiencia de revisión de archivos en GitHub no me convence
    • Extraño muchísimo la UI de revisión de Phabricator

  • ¡Por fin salió!
    El modelo de GitHub de “PR = branch” no me hacía sentido
    El enfoque de stacked commit al estilo Phabricator/Gerrit encaja mucho mejor con mi forma de pensar
    Ahora tendré que instalar el CLI

    • Es una lástima depender del GH CLI, pero ojalá cuando llegue a GA también haya soporte en la UI
    • En mi modelo mental no tengo muy clara la diferencia entre branch y stacked PR
      Una branch solo pone una bandera sobre un commit, y dejar varios puntos solo tiene sentido cuando las partes anteriores se pueden mergear de forma independiente

  • Me pregunto si ya resolvieron el problema de UX de Squash & Merge
    Yo los apilo manualmente como main <- PR A <- PR B <- PR C,
    y cuando PR A se mergea primero, PR B se convierte en un infierno de conflictos
    La UI de GitHub cambia automáticamente la branch objetivo a main y aparecen conflictos raros
    Solo necesito una herramienta que “simplemente funcione”

    • Es muy probable que los conflictos se deban a que PR A fue mergeado con squash
      Ojalá gh stack sync lo resuelva con rebase --onto
    • En la práctica, el CLI y el servidor lo manejan con git rebase --onto
      Ejemplo: PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      Si PR1 y PR2 se mergean con squash, main queda como S1(A+B), S2(C+D)
      Luego git rebase --onto S2 D branch3 lo reordena sin conflictos
    • En mi flujo de trabajo, cuando A se mergea, B también debería quedar ya mergeado
      Se puede resolver con git rebase --update-refs --onto origin/main A C
      El GH CLI automatiza ese proceso
    • Este problema es una limitación lógica de git, no un bug
    • También coincido en que esto es molesto y poco intuitivo
      Pero al final la solución sigue siendo reorganizar commits con rebase manual

  • Cuando desarrollas solo, casi nunca necesitas stacked PR, pero el hábito de dividir en unidades pequeñas sigue siendo importante
    Como las herramientas de IA (por ejemplo, Claude Code) generan diffs grandes de una sola vez,
    sería interesante que apareciera una función donde el agente pudiera dividir el trabajo por su cuenta en unidades lógicas

    • Los PR ya pueden estar compuestos por varios commits, así que si el agente no sabe navegar bien eso, con stacked PR tampoco cambiará mucho
    • Yo uso Claude junto con jj para que reestructure la pila de trabajo sobre trunk de una forma amigable para review
    • Si haces que branches pequeñas dependan entre sí, se genera un infierno de sincronización cuando se actualiza una branch anterior
    • En la página web se puede consultar una guía de integración de agentes relacionada

  • También vale la pena revisar git-spice
    Es compatible con GitLab y otros, y yo uso git-spice para todo en lugar de los comandos normales de git

  • Está genial que GitHub por fin haya agregado una función de stack a la UI
    Es similar a glab stack de GitLab
    Aun así, el proceso de merge parece un poco incómodo: si haces merge de la parte baja del stack, el resto se rebasea y el CI vuelve a correr
    Si quieres mergear solo los dos de abajo de tres parches, tienes que esperar las pruebas de cada uno

    • Según el diseño actual, si el CI de los dos PR inferiores pasa, se pueden mergear de una sola vez
      Después de eso, el stack superior se rebasea y el CI puede ejecutarse de nuevo
      Vamos a añadir esa parte con más claridad en la documentación

  • No termino de ver la necesidad de stacked PR
    En git originalmente ya se pueden revisar y aplicar patch sets por separado
    El modelo de PR más bien los termina agrupando en un solo bloque
    Stacked PR me parece otra abstracción más para esquivar ese problema

    • En el equipo donde trabajé, el PR en sí se veía como la “unidad mínima aplicable”
      Los commits internos eran solo historial de desarrollo, y al mergear se juntaba todo con squash en uno solo
      Así puedes apilar commits libremente durante el desarrollo y, al mergear, solo dejas un cambio limpio
    • En Phabricator la relación entre commit y diff era 1:1, así que se sentía mucho más natural
      La implementación de GitHub se siente un poco como una función pegada encima
    • El PR originalmente es una unidad de cambio atómica, y stacked PR te permite trabajar sobre un PR nuevo basado en ese
      O sea, es una estructura para apilar trabajo por etapas en unidades revisables

  • Ya hay una startup llamada Graphite enfocada en stacked PR
    Yo he usado Graphite, y me da gusto que GitHub haya implementado algo parecido

    • En mi empresa también usamos Graphite y estamos satisfechos

  • Me gustan los stacked PR, pero esta implementación de GitHub me parece extraña
    Bastaría con que cada branch apuntara a su padre
    Más que CLI, hace falta soporte en la UI

    • Pero después de que la branch padre se mergea, hacer rebase es doloroso
      Estaría bien que el CLI automatizara ese proceso
    • El CLI es opcional, y también se pueden crear stacked PR desde la UI
      La razón de tener una cadena de branches es que el diff solo muestre los cambios de esa branch
    • En realidad esto ya era posible con git
      Lo que faltaba era UI y visualización
    • Ojalá lo próximo sea una mejora de la UI