Stacked pull requests do GitHub agora estão disponíveis para todos

O GitHub liberou as stacked pull requests para todos em 6 de outubro de 2026, em todos os planos do github.com. Uma pilha permite que um desenvolvedor divida uma mudança grande em uma cadeia de pull requests pequenas, revisadas uma de cada vez e depois mescladas juntas. O recurso estava em prévia pública desde 30 de julho, e o GitHub diz que as equipes que o usam já mesclam mais código.

O que é uma stacked pull request

Uma pull request (PR) pede para mesclar um branch de código em outro. PRs grandes são lentas de revisar, porque o revisor precisa entender tudo de uma vez.

Uma pilha divide esse trabalho em camadas. Cada PR aponta para o branch logo abaixo, então cada uma mostra apenas a sua própria parte das mudanças. A PR da base aponta para o branch principal, muitas vezes chamado de trunk. Segundo o changelog do GitHub, cada camada recebe suas próprias revisões e verificações antes de as camadas entrarem juntas.

O merge acontece de baixo para cima. O CCLeaks, que publicou um guia de configuração em 8 de outubro, explica que mesclar uma PR também faz entrar todas as PRs não mescladas abaixo dela. Mesclar a PR do topo mescla a pilha inteira. As regras de branch continuam valendo para cada camada, incluindo revisões obrigatórias, verificações de status e code owners.

O que mudou com a disponibilidade geral

O changelog de 6 de outubro lista estas mudanças desde a prévia:

Mudança	O que faz
Aprovações sobrevivem a rebases	Fazer rebase de uma pilha mantém as aprovações no código inalterado, mesmo em repositórios que descartam aprovações desatualizadas
Commits assinados	Commits reescritos durante um rebase da pilha continuam assinados e mantêm o autor original
Merge queue	Uma pilha entra na fila de merge como um único grupo e entra de uma vez
Commits de merge	Com o método merge commit, cada PR da pilha recebe seu próprio commit de merge
Branch base excluído	A pilha é redirecionada em vez de a PR da base ser fechada
Merges com bypass	Usuários que podem contornar as regras do repositório conseguem mesclar a PR não mesclada mais baixa

O auto-merge para pilhas ainda está sendo liberado "nas próximas semanas", segundo o GitHub. O cabeçalho da PR agora mostra detalhes da pilha, e a linha do tempo registra quando uma PR entra ou sai de uma pilha. Os webhooks ganham uma ação stacked no evento pull_request. O GitHub Enterprise Server, a edição auto-hospedada, recebe as pilhas "em uma próxima versão".

Os números que o GitHub divulga

O GitHub diz que os repositórios que usam pilhas mesclaram 9% mais código do que seus pares. A empresa também relata uma melhora de 5% no tempo até o merge. São números do próprio GitHub, e o changelog não explica como o grupo de comparação foi escolhido.

Os primeiros usuários parecem satisfeitos. "Bastou um merge com as Stacked PRs do GitHub para eu concluir que é incrível", diz Charlie Marsh, fundador da Astral, citado no changelog. No post da prévia de julho, Tim Neutkens, líder do Next.js na Vercel, disse: "Estamos usando as stacked PRs do GitHub no Next.js nos últimos meses."

Como começar uma pilha

As pilhas são controladas pelo gh stack, uma extensão para a GitHub CLI, a ferramenta de linha de comando do GitHub. O CCLeaks lista como requisitos GitHub CLI 2.90.0 ou mais recente e Git 2.20 ou mais recente. A versão GA adiciona suporte a worktrees do Git, que permitem que um repositório mantenha vários branches em checkout em pastas separadas.

O fluxo básico, segundo o guia do CCLeaks:

1. Instale a extensão com gh extension install github/gh-stack.
2. Rode gh stack init para iniciar uma pilha e depois gh stack add <branch> para cada camada.
3. Rode gh stack submit para abrir as PRs e gh stack view para ver a cadeia.
4. Rode gh stack rebase quando o branch base avançar.

O post da prévia de julho diz que as pilhas também podem ser criadas no github.com, no app móvel do GitHub ou por um agente de programação como o GitHub Copilot usando a skill gh-stack. Na interface web, Shift+J e Shift+K alternam entre as PRs de uma pilha.

Limites para conhecer antes

O recurso tem limites rígidos. O CCLeaks lista estes:

• Um único repositório. Todos os branches precisam estar no mesmo repositório, então pilhas entre forks não funcionam.
• Só linhas retas. Uma pilha não pode se ramificar; uma PR não pode ter duas filhas.
• Sem GitHub Desktop. O app de desktop não oferece suporte a pilhas.
• Endpoints de merge antigos falham. Os endpoints legados da API de merge de PRs não conseguem mesclar uma pilha.
• Grupos de fila maiores. O grupo de uma pilha na fila de merge pode passar do tamanho máximo configurado em até 50%. Ejetar uma PR também remove todas as PRs acima dela.

O que isso significa para desenvolvedores

Equipes que dividem trabalhos grandes em branches dependentes à mão agora ganham um fluxo nativo. Antes de migrar, vale checar algumas coisas.

• Confira sua automação. Bots que fazem merge por endpoints antigos da API vão falhar com pilhas. O CCLeaks diz que os dados da pilha chegam ao GitHub Actions como github.event.pull_request.stack, e que o campo stack da API REST é null para PRs avulsas. Atualize os bots de merge para que o leiam.
• Revise os limites da fila de merge. Se a sua fila limita o tamanho dos grupos para proteger a capacidade de CI, uma pilha pode levar um grupo até 50% acima desse limite.
• Contribuidores vindos de forks vão ter que esperar. Projetos open source que aceitam mudanças de forks ainda não conseguem empilhar essas PRs.
• Planeje para depois os upgrades do Enterprise Server. Clientes auto-hospedados não têm data, apenas "uma próxima versão".
• Teste em uma mudança grande. Uma refatoração que mexe em muitos arquivos é um primeiro teste natural. Divida-a em três ou quatro camadas e veja se as revisões voltam mais rápido.

O número de 9% é uma afirmação do GitHub sobre o próprio produto. Os seus próprios tempos de revisão, antes e depois, são o número que vale a pena acompanhar.