GitHub inicia prévia pública de Stacked PR

• Stacked pull requests, que dividem grandes mudanças em camadas pequenas e revisáveis, estão sendo disponibilizados gradualmente em prévia pública para todos os repositórios
• Cada PR tem como alvo a camada imediatamente abaixo, permitindo que a equipe faça revisões independentes em paralelo com diffs de escopo mais estreito
• Ao mesclar o PR mais recente, todas as camadas não mescladas abaixo também são incluídas de uma vez; se apenas parte for mesclada, os PRs superiores passam por rebase automático e mudança de destino
• Revisão de PR já existente, verificações obrigatórias, proteção de branch e requisitos de merge continuam valendo, e é possível trabalhar com stacks no GitHub.com, CLI, app móvel e GitHub Copilot
• A prévia pública será expandida para todos os repositórios ao longo de alguns dias, e o suporte a Merge queue será liberado gradualmente nas semanas seguintes

---

Estrutura de PR em stack para pequenas mudanças

• Grandes mudanças são divididas em vários PRs pequenos e focados, com cada PR compondo uma camada de mudança ordenada
• Depois de criar a branch e o PR da primeira mudança, adicionam-se novas branches e PRs por cima, com cada PR apontando para a camada imediatamente abaixo
• Isso reduz o incômodo de revisar um único PR enorme ou de continuar fazendo rebase manual de várias branches
• A equipe do Next.js avaliou que, mesmo ao lançar recursos grandes, conseguiu manter mudanças individuais pequenas e facilitar a revisão de PRs

Criação de stacks e ambiente de trabalho

• A extensão de CLI é instalada com o seguinte comando

gh extension install github/gh-stack

• É possível criar e gerenciar stacks no GitHub.com, GitHub CLI e aplicativo móvel do GitHub
• Em agentes de programação como o GitHub Copilot, é possível usar a skill gh-stack

Revisão independente por camada

• Ao abrir um PR dentro de uma stack, é possível revisar apenas o diff daquela camada, e não a mudança inteira
• No mapa da stack no topo do PR, dá para ver onde a mudança atual se encontra dentro do trabalho como um todo
• Integrantes da equipe podem revisar camadas diferentes em paralelo, sem que o trabalho seguinte fique bloqueado até a revisão terminar
• As regras existentes de proteção de branch podem ser aplicadas junto com revisões por camada para controlar a qualidade em cada etapa
• A TED afirmou que, depois que a adoção de IA aumentou a produtividade de desenvolvimento, PRs maiores passaram a gerar gargalos de revisão; ao dividir mudanças em pequenas unidades lógicas de acordo com a ordem de dependência, aumentou a velocidade e a precisão da revisão

Mesclar toda a stack ou apenas parte dela

• Ao mesclar o PR mais recente que estiver pronto, esse PR e todas as camadas não mescladas abaixo dele são aplicados de uma vez
• Também é possível escolher primeiro a mesclagem de apenas uma ou mais camadas inferiores da stack
  • Os PRs superiores permanecem abertos
  • Eles passam automaticamente por rebase e também têm a branch de destino alterada para refletir as mudanças já mescladas
• As regras existentes de proteção de branch, verificações obrigatórias e requisitos de merge continuam valendo para controlar as mudanças que entram na main
• É possível mesclar seletivamente não só a stack inteira, mas também uma única camada ou apenas algumas camadas

Prévia pública e cronograma de suporte

• Stacked pull requests serão distribuídos gradualmente em prévia pública para todos os repositórios ao longo de alguns dias
• O suporte a Merge queue será liberado gradualmente ao longo das semanas seguintes
• Mais detalhes de uso podem ser encontrados na documentação de stacked pull requests, e o feedback está sendo coletado na discussão sobre stacks

[GN⁺]

Comentários do Hacker News

• Usei a prévia por um tempo e me surpreende que estejam ampliando o alcance enquanto ainda há muitos problemas sem solução
  Por exemplo, mesclar a stack inteira quebra completamente em várias situações: https://github.com/github/gh-stack/discussions/212
  Dá para mesclar um por um, mas se você usa squash merge junto com revisão obrigatória, precisa obter nova aprovação para cada PR da stack, perdendo a maior vantagem dos PRs em stack
  gh stack reduz um pouco o trabalho manual, mas ainda é preciso entender git rebase com precisão. Se a branch local não estiver sincronizada com a remota, até o gh stack rebase sugerido pela UI falha, e a ferramenta não diz o motivo
  Por outro lado, gostei da UI de stack por ser simples e ainda mostrar bem as relações entre os PRs. Partindo do pressuposto de que já existe um motivo para empilhar PRs, ela só torna o fluxo de trabalho mais confortável, e não é uma ferramenta que traz uma nova funcionalidade

  • Estamos lançando em etapas correções de bugs para resolver o problema do squash merge
    O CPRMC interno (Create Pull Request Merge Commit) determina se um PR está pronto para ser mesclado verificando desde a existência de conflitos até se o conteúdo aprovado corresponde ao commit que será realmente gerado
    Para fazer squash merge de vários PRs, é preciso calcular commits squash consecutivos e depois reconectá-los às regras e às revisões. O primeiro PR é relativamente fácil, mas a partir do segundo fica complicado porque os commits ancestrais foram condensados por squash e não existem mais na branch em sua forma original; quando há situações com vários pais, é muito mais difícil
    Atualmente, 99% das mesclagens de stack têm sucesso, mas elevar bastante esse número é a prioridade máxima da equipe
  • Hoje apaguei a branch apontada por um PR em stack e encontrei um bug em que ele fica parado no estado merging sem orientação adicional
    Cheguei a verificar a página de status do GitHub achando que fosse uma indisponibilidade parcial do sistema de PR, mas era um bug da própria funcionalidade de PR em stack
  • Parece que, desde 2021, a indústria inteira mudou completamente para o modo ready, fire, aim
  • Na empresa também tivemos muitos problemas recentemente por causa dessa funcionalidade e da merge queue

• A equipe de GitHub Stacked PRs agora está abrindo mais amplamente para que qualquer pessoa possa criar stacks: https://gh.io/stacks
  Eles querem especialmente feedback sobre a UI e a CLI, e também estão preparando muitas atualizações para melhorar a experiência de uso de PRs
  Como este é um dos maiores lançamentos da história do GitHub, abrangendo quase todos os serviços, de Actions e regras de proteção até CLI e aplicativo móvel, eles também podem responder perguntas sobre decisões de design e funcionamento interno

  • Testei pela primeira vez hoje e gostei do resultado
    Já uso uma UI local própria para ver as dependências de PRs em stack como uma árvore e gerenciar o estado de revisão e CI de cada PR, então seria bom se a UI web do GitHub também tivesse árvore e indicadores de estado
    A UI web aparentemente não suporta mesclar apenas o PR da base da stack, mas como dá para compartilhar o fluxo de trabalho e o código existentes, espero que isso entre também nas ferramentas nativas do GitHub
  • Fico curioso se pretendem oferecer suporte em breve a PRs em stack atravessando forks
    Parece um recurso importante para ser útil em repositórios públicos, então surpreende que isso não tenha sido lançado antes da prévia pública
  • Era exatamente esse o recurso de que eu mais sentia falta do Gerrit
  • Fico curioso por que escolheram PRs adicionais como unidade de divisão do trabalho
    Em vez de uma UI de verdade para revisar, aplicar e modificar por commit, queria saber se houve algum insight específico por trás de ignorar o fluxo de trabalho de series de patches das mailing lists, que foi a origem dessa abordagem, e basicamente optar por um “pacote de pacotes de patches”

• Uma das maiores mudanças aplicadas ao GitHub em anos
  Com a introdução de um fluxo de trabalho em stack em uma das maiores plataformas de hospedagem de código do mundo, muitos desenvolvedores podem acabar conhecendo uma abordagem cuja existência nem sabiam
  Se a premissa de que stacks produzem software melhor estiver correta, isso pode de fato ajudar muita gente

• Fico curioso sobre qual é a vantagem desses PRs em stack em comparação com revisar commits bem organizados, um por um
  O problema maior é que PRs grandes gerados por IA exigem um modo de revisão diferente. Só a ordem em que as diferenças são mostradas — por exemplo, mudança de definição de função, pontos de chamada, testes — já muda muito a facilidade de leitura
  Talvez seja necessário um diff letrado ou PR letrado que combine diferenças e explicações, assim como a programação letrada entrelaça código e prosa, mas ainda não encontrei uma ferramenta parecida

  • Para quem usa diffs em stack no Phabricator e afins, isso já é justamente a forma de revisar commits bem organizados, um por um
    Como a unidade de revisão, seja PR ou diff, continua sendo uma mudança limitada, a discussão fica focada nessa alteração, e mesmo se a funcionalidade crescer o PR em si não fica inchado
    Além disso, é possível atribuir cada parte da stack a pessoas diferentes. Se você separa revisores entre time externo, colegas do mesmo time e o time que usa a mudança, não fica ambíguo o que cada um está aprovando
    Seria ainda melhor se a revisão do GitHub introduzisse change ID para manter os comentários após rebase
  • Se você adiciona um commit ao primeiro PR da stack, pode inseri-lo no meio da ordem de commits da stack inteira
    Depois, precisar fazer rebase e ajustes nos PRs seguintes é igual a corrigir commits posteriores de um único PR gigante, mas em vez de anexar commits temporários de correção aleatoriamente à mudança toda, fica mais fácil manter juntos os commits da mudança de base
    A discussão sobre a mudança de base também fica reunida, e apresentar a stack inteira de antemão permite que o revisor entenda a direção final enquanto o trabalho continua de forma assíncrona
  • O ponto central é que não são tantas as pessoas que realmente criam commits “bem organizados”
    Muita gente usa commits como save points de jogo, deixando mensagens como fix bug, do work, e depois não organiza com git rebase -i; então, se o squash merge obrigatório não estiver ativado, o histórico fica cheio de commits lixo
    Para esses desenvolvedores, o PR é o commit, e os PRs em stack finalmente permitem usar uma estrutura parecida com vários commits que compõem uma única mudança
  • Com stacks, você pode continuar um trabalho longo criando sempre diffs de tamanho revisável
    Os diffs já mesclados podem receber rebase em cima do HEAD atual e, em equipes que dão suporte a isso, normalmente não se gerenciam branches diretamente, mas se trabalha no trunk e se faz rebase sempre que entra alguma mudança
  • Em PRs, não dá para mesclar commits um por um, mas em stacks isso é possível
    Se as 4 primeiras partes de uma funcionalidade estão prontas e há problema na quinta, não é necessário bloquear tudo

• Tenho curiosidade sobre quando haverá suporte para casos em que PRs com dependências formam uma estrutura em árvore, e não um histórico linear
  Quando usei mudanças em pilha no Google, isso era comum, e agora, com o aumento de agentes de codificação paralelos, parece que isso deve acontecer ainda mais

  • Já é uma estrutura difícil para humanos gerenciarem, então fico em dúvida se é mesmo desejável que o software e a IA associada incentivem esse modo de trabalho

• Fiquei curioso se o motivo de o botão de alternância do menu ser o emoji de uma pilha de panquecas (U+1F95E) é por causa do recurso de stack
  A brincadeira em si tudo bem, mas foi uma UI que gerou forte dúvida sobre o que eu estava vendo

  • Internamente usaram o emoji de panqueca como um easter egg divertido
    A ideia é mostrá-lo só por algumas horas e depois voltar para o ícone normal
  • Sim: https://github.com/orgs/community/discussions/203497

• Desde que ouvi a notícia pela primeira vez, usei o CLI gh stack, e a ferramenta em si é muito boa, mas a UI web que vi ao ser aprovado para o preview ficou muito aquém do esperado
  Mesmo antes da aprovação, o CLI já facilitava automatizar a divisão do trabalho em vários PRs atômicos, mas ao fazer push eles apareciam como PRs independentes, sem ligação entre si
  Depois da aprovação, continua quase igual: a única diferença é que outros PRs da mesma stack aparecem em um pequeno menu suspenso de navegação no topo, então não há uma mudança significativa de UI
  Dá para executar parte das funções do CLI pelo menu suspenso, mas isso parece mais uma conveniência secundária, como editar arquivos pela web, e no fluxo real de desenvolvimento o centro continuará sendo o CLI ou um plugin de IDE
  Por causa de uma UI opcional desse nível, fico sem entender por que demoraram tanto para liberar isso amplamente, sendo que o CLI de stack já estava em disponibilidade geral desde o anúncio

  • No começo precisávamos partir com o mínimo de funcionalidades, mas estamos trabalhando em uma reformulação muito mais ampla da UI de PR
    Também vamos incluir telas que mostrem a stack de forma persistente, sempre com reconhecimento da pilha e permitindo navegar entre os níveis sem tantos cliques

• Gosto do fato de que o jujutsu, ao atualizar uma branch, também faz automaticamente o rebase de outras branches que saíram dela
  Quando separo o trabalho para facilitar a revisão, frequentemente mudo para jj, e ele funciona bem junto com um clone feito com Git no mesmo diretório de trabalho

  • jj absorb também é excelente
    Ele move mudanças para a alteração relacionada mais próxima, então até correções que afetam vários PRs ficam fáceis de lidar

• Depois de usar o Graphite, ficou muito difícil voltar para o GitHub sem stacks
  Espero que o suporte do GitHub torne o fluxo de trabalho com PRs em pilha mais comum e crie uma alternativa fácil aos PRs gigantes

  • Recomendo git-spice
    É open source, fácil de usar e poderoso; o Graphite me pareceu complexo demais para o que oferece

• Eu entendia que empilhar PRs era útil em duas situações
  A primeira é quando o trabalho se espalha por vários repositórios relacionados e não pode ser reunido em um único PR; a segunda é quando você faz o trabalho em pipeline, empilhando PRs subsequentes sobre a mesma branch enquanto o primeiro PR está em revisão
  Mas este recurso não atende nenhuma das duas e parece apenas outra forma de empilhar commits em um único PR
  Em geral, basta criar commits atômicos e significativos e, com rebase, organizar um fluxo fácil para o revisor entender; se quiser, o revisor também pode analisar commit por commit
  Fico curioso sobre qual seria a vantagem única que estou deixando passar nesse modelo