PRs empilhados já estão disponíveis no GitHub
O novo recurso de pull requests empilhados do GitHub, agora em prévia pública, pretende ajudar desenvolvedores a dividir grandes mudanças de código em uma série de PRs menores e dependentes, que podem ser revisados e mesclados com mais facilidade. Muitos engenheiros acolhem o suporte nativo para um fluxo de trabalho que antes emulavam com ferramentas de terceiros ou branching manual, destacando benefícios para CI, escopo de revisão e trabalho paralelo. Outros argumentam que o recurso é incompleto, bugado ou redundante com commits bem estruturados, e alguns criticam o GitHub por ignorar trabalhos anteriores em sistemas como Gerrit e Phabricator ou por lançar mais uma camada de complexidade em vez de melhorar as ferramentas centrais de revisão.
Recepção geral
- Muitos estão animados; PRs empilhados são descritos como uma das maiores mudanças do GitHub em anos e um recurso que faltava há muito tempo em comparação com outros sistemas.
- Outros estão pouco impressionados, chamando isso בעיקרamente de “UI sugar” em cima de padrões que já usavam (PRs apontando para outras branches de PR).
- Alguns acham que chegou tarde e que é básico/com bugs para uma v1; outros estão simplesmente felizes por não ser mais um recurso de IA.
Benefícios de fluxo de trabalho percebidos
- Permite dividir recursos grandes em unidades menores, revisáveis, enquanto o trabalho continua nas partes posteriores.
- Possibilita revisão paralela: refatoração → backend → frontend, com revisores diferentes por camada.
- Suporta mesclar subconjuntos de uma pilha de recursos (por exemplo, infraestrutura + API, mas não UI) e executar CI por unidade.
- O gerenciamento de pilha (auto-rebase de PRs dependentes, merge-um-ou-merge-todos) é visto como uma grande vantagem em relação ao rebase manual.
Críticas e limitações
- Alguns veem PRs empilhados como um paliativo para problemas organizacionais/de revisão; em vez disso, defendem melhor higiene de commits e PRs menores e independentes.
- Há preocupação de que empilhar aumente a complexidade, incentive branches de longa duração e adicione pressão sobre revisores (“mudar a base de uma pilha de 5 níveis é doloroso”).
- A implementação atual tem bugs, especialmente em torno de squash merging de pilhas e interações com a fila de merge; suporte entre repositórios e suporte completo a forks ainda estão ausentes.
- Vários dizem que isso não resolve as partes difíceis: reordenar trabalho local bagunçado em séries coerentes, verdadeiras pilhas entre repositórios ou árvores/grafos de mudanças dependentes.
Preocupações com revisão e UI
- A unidade de revisão do GitHub ainda é o PR; revisar commit a commit é complicado, e comentários não se mapeiam de forma limpa para commits em evolução.
- Alguns gostariam que o GitHub tivesse adotado um modelo de diff/série de patches com change IDs e interdiffs, como Gerrit/Phabricator e grandes forjas internas.
- A interface web para pilhas é vista como mínima; usuários sérios esperam depender da CLI ou de ferramentas personalizadas.
IA e contexto mais amplo
- Vários comentários associam PRs empilhados ao aumento de diffs gerados por IA e a fluxos de trabalho com agentes, como forma de manter as revisões em escala humana.
- Outros enfatizam que fluxos de trabalho empilhados existem muito antes da IA; este recurso בעיקרamente populariza uma prática já estabelecida.