Stacked pull requests do GitHub chegam à disponibilidade geral: o que muda no rebase, na merge queue e no auto-merge

Fala aí, beleza? Em 6/10/2026 o GitHub anunciou no Changelog que os stacked pull requests chegaram à disponibilidade geral (GA) 😀

A ideia é simples: em vez de um PR gigante que ninguém quer revisar, tu quebra a mudança em PRs menores, cada um revisado de forma independente, e depois mergeia tudo junto

E a GA não é só uma troca de selo, não

Veio com mudanças no rebase, na merge queue, no bypass de regras e com auto-merge a caminho

Bora ver o que mudou?

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que são stacked pull requests no GitHub?

Segundo a documentação de stacked pull requests, uma stack é uma série de pull requests no mesmo repositório

O PR de baixo (bottom) aponta para o trunk da stack, que normalmente é a branch padrão, tipo main

Cada PR seguinte aponta para a branch do PR que está abaixo dele, como degraus de uma escada

E cada camada pode ser revisada e aprovada de forma independente, esse é o pulo do gato 🙂

O trunk precisa ser a main?

Não! Por padrão é a branch padrão, mas o trunk pode ser uma branch de release ou uma feature branch de longa duração

No site, basta criar o PR de baixo contra a branch que você quer usar como base

E as regras de proteção?

Aqui tem um detalhe importante: todo PR da stack é avaliado pelas regras da base da stack (normalmente a main), independentemente da branch para a qual ele aponta diretamente

Ou seja, não dá pra driblar proteção só porque o PR do meio aponta pra outra branch haha

De onde veio e o que o GitHub diz dos resultados

O recurso entrou em public preview em 30/07/2026, com liberação para todos os repositórios nos dias seguintes

De acordo com o próprio GitHub, repositórios que usam stacks tiveram 9% a mais de código mergeado em comparação com repositórios semelhantes

O GitHub também diz que mais de dois terços do top 1% dos repositórios já usam stacked PRs e tiveram melhora de 5% no time-to-merge

Vale reforçar: esses números são do GitHub, não de medição independente

Rebase stack agora preserva aprovações e mantém commits assinados

Se liga no problema clássico: a main anda, tu precisa atualizar a stack e… lá se vão as aprovações que o time já tinha dado

Com a GA, quando uma stack sem outras mudanças é atualizada depois que a branch base avança, o Rebase stack mantém as aprovações

Isso vale inclusive em repositórios que usam dismiss stale approvals (descartar aprovações obsoletas), que é justamente onde a dor era maior

Outra mudança: o GitHub cria commits substitutos assinados durante o Rebase stack, preservando a autoria original

E os rebases automáticos depois de merges parciais também assinam os commits quando as regras da branch exigem assinatura ou quando algum commit original era assinado

Pra quem tem assinatura obrigatória, isso tira um atrito bem chato do caminho

Merge queue, bypass e retarget automático: como o merge da stack mudou

São três mudanças no momento do merge, bora uma por uma

A stack entra na merge queue como um único grupo

Agora a stack entra e é mergeada pela merge queue como um único merge group

E com o método merge commit, o GitHub cria um merge commit por pull request, e não um só para o grupo inteiro

Na prática, o histórico continua refletindo cada PR da stack

Permissões de bypass valem para stacks

Quem tem permissão para ignorar regras do repositório pode usar essa permissão para mergear o PR não mergeado mais baixo da stack

Retarget automático quando a base some

Se a branch base de uma stack é apagada, o GitHub faz o retarget automático da stack em vez de fechar o PR de baixo

Isso atende aqueles fluxos em que uma stack sai de outra stack, que antes podiam virar uma bagunça 😛

Auto-merge de stacks: o que é e quando chega?

O auto-merge de stacks está em liberação gradual nas próximas semanas depois de 6/10/2026

Pelo que o GitHub descreve, você seleciona um grupo de PRs e eles são mergeados juntos quando todos atenderem aos requisitos de merge do repositório

Não tem data exata de quando a liberação termina, então pode ser que ainda não apareça pra você

Navegação, timeline e webhook: o que muda na interface e nas integrações

As informações da stack agora ficam sempre visíveis no cabeçalho fixo da página do PR

E os detalhes da stack também aparecem na lista de pull requests, sem precisar abrir PR por PR

Pra navegar entre os PRs da stack, tem atalho: Shift+J e Shift+K

A timeline passa a mostrar eventos quando um PR entra ou sai de uma stack

E o webhook pull_request ganha a ação stacked quando um PR entra numa stack

Esse último é o que interessa pra quem mantém bot e automação em cima de PR: se tu já roda algo como o AI Scan em pull requests, agora dá pra reagir especificamente à entrada de um PR numa stack

No changelog, David Mostoller, engenheiro de software da Comcast, conta que ver todas as branches da stack na interface de PR, checar o status de cada uma e navegar entre elas facilitou MUITO revisar vários PRs dependentes

O changelog também traz um depoimento de Charlie Marsh, fundador da Astral: segundo ele, bastou um merge com os Stacked PRs pra concluir que são incríveis

gh stack com worktrees: stacks no terminal e com agentes de código

A extensão gh stack do GitHub CLI passou a suportar Git worktrees

Também ficou mais rápida na inicialização, no checkout e na navegação

Que worktree? É o recurso do Git que deixa você ter várias branches do mesmo repositório abertas em pastas diferentes ao mesmo tempo, sem ficar trocando de branch toda hora

A instalação vem do repositório github/gh-stack e usa a autenticação do próprio GitHub CLI:

gh extension install github/gh-stack

# se ainda não autenticou no gh
gh auth login

Os comandos principais, segundo a documentação:

gh stack init     # inicia a stack
gh stack add      # cria uma nova branch no topo da stack
gh stack view     # mostra a stack
gh stack submit   # faz push de todas as branches e cria/atualiza os PRs
gh stack sync     # fetch, rebase, push e sincroniza o estado dos PRs
gh stack rebase   # rebase em cascata na stack

# navegação
gh stack up
gh stack down
gh stack top
gh stack bottom
gh stack trunk

Se tu tá na dúvida entre usar o terminal ou MCP pra mexer em PR com IA, já falei disso no comparativo de gh CLI ou GitHub MCP

E os agentes de código?

Aqui mora um benefício bem prático pra quem faz vibe coding: agente de IA adora gerar mudança gigante, e revisar um PR de mil linhas não é nada massa

Quebrar essa mudança em PRs menores e revisáveis deixa a revisão humana possível de novo

Com o suporte a worktrees na gh stack, fica mais fácil também organizar fluxos paralelos, cada um na sua pasta

Segundo o GitHub, dá pra trabalhar com stacks pelo github.com, pelo GitHub CLI, pelo app GitHub Mobile ou por um agente de código como o GitHub Copilot usando a skill gh-stack

Pra entender melhor como skills funcionam na prática com agentes, este vídeo do canal mostra uma skill do GitHub que pesquisa a internet inteira por você:

Quem se beneficia e quais são as limitações?

Quem mais ganha com a GA:

• Times que revisam muitos PRs dependentes entre si
• Repositórios com dismiss stale approvals ativo, que antes perdiam aprovação a cada atualização da base
• Repositórios que exigem commits assinados
• Quem usa merge queue e quer a stack entrando como um grupo só
• Quem mantém bots e automações via webhook
• Quem trabalha com agentes de código e precisa fatiar mudanças grandes

Agora as limitações, sem enrolação:

• O auto-merge de stacks está em liberação gradual nas próximas semanas depois de 6/10/2026, então pode ser que ainda não apareça no seu repositório
• O GitHub Enterprise Server vai receber o recurso numa versão futura, ainda sem data
• Todo PR da stack continua sujeito às regras de proteção da base da stack, então planeje as regras pensando nisso

Próximo passo

Os stacked pull requests já estão disponíveis em todos os planos do github.com

O próximo passo é dar uma olhada na documentação oficial ou instalar a extensão gh stack e fazer o teste num repositório seu

E vale ficar de olho no Changelog pra ver quando o auto-merge chega pra você e quando sai a versão do GHES com o recurso…

Até o próximo post! 😀