Cassidy Williams, do GitHub, publicou em 30 de julho um relato de uso das sessões empilhadas no app do GitHub Copilot. Ela define a ideia como uma série de tarefas no mesmo repositório em que cada sessão parte da anterior.
O caso contado
O exemplo é um projeto pessoal dela, de uns 2014, que usava React 15. Ela queria modernizar o front-end. Sem IA, estima que seriam semanas de trabalho.
Foram três sessões. A primeira tentou a modernização completa do front-end. Na segunda, ela descobriu que já havia trabalho paralelo em outra branch e passou a trabalhar em cima dessa. A terceira ficou empilhada sobre a segunda, para refatorações adicionais. O app criou os pull requests encadeados, cada um apontando para a branch do PR anterior.
Como o app funciona, segundo o texto
O Copilot app recebe um repositório e pedidos em linguagem natural, tem um modo de plano, abre pull requests e conduz fluxos de várias etapas. A pessoa descreve a mudança e os pontos em que quer aprovar antes da execução. O post não documenta comandos, e a conversa com o agente é o fluxo principal.
O que o post não responde
- se as sessões empilhadas servem especificamente para código legado ou para qualquer desenvolvimento (o título antigo deste post presumia refatoração de legado, e por isso o mudei);
- planos, preços ou se é preview;
- limitações, que o texto não discute;
- métricas de sucesso, já que é um único relato pessoal.
O valor prático é mais simples do que o título sugere: quando uma mudança grande depende de etapas em sequência, você quer revisar uma de cada vez. Isso casa com o que o guia do GitHub sobre PRs empilhados propõe do lado da revisão.
