Agentes de código costumam entregar uma funcionalidade inteira num único pull request. Julia Muiruri, do GitHub, escreveu um guia para transformar esse PR gigante em uma pilha de PRs menores, cada um com uma preocupação só. O post saiu em 4 de agosto.
O exemplo do post
O caso é um assistente de compras com busca de produtos. Feito de uma vez, o PR teria 1.721 linhas alteradas. O post divide em quatro camadas, da base para o topo:
- L1,
feat/catalog-data: catálogo de dados com validação; - L2,
feat/search-api: endpoint de busca; - L3,
feat/chat-grounding: integração do chat com a API; - L4,
feat/grounded-ui: citações e cartões de produto na interface.
A lógica é colocar o trabalho de fundação embaixo e empilhar o que depende dele por cima. Assim dá para escolher revisores por assunto: quem conhece os dados olha a L1, quem cuida da interface olha a L4.
A ferramenta
O fluxo usa a extensão gh-stack do GitHub CLI, instalada com gh extension install github/gh-stack. Os comandos citados são gh stack add para criar uma camada, gh stack push para enviar as branches, gh stack submit para abrir os PRs encadeados, gh stack rebase para rebase local e gh stack sync para propagar mudanças pela pilha.
Um cuidado com assinatura de commit
O post avisa que o botão de rebase da pilha na interface web redefine as informações do committer e remove as assinaturas dos commits. Se a sua branch protegida exige commits assinados, isso pode quebrar a regra. A alternativa indicada é rodar gh stack rebase localmente e depois gh stack push. O texto também lembra que o CI precisa rodar contra a base de cada camada.
O que o texto não cobre
Não há recomendação de tamanho máximo para cada camada, nem discussão sobre estratégia de merge (squash, rebase ou fast-forward), nem dados mostrando que a revisão ficou mais rápida. É um tutorial de fluxo de trabalho, não uma medição.
