Distribuir solicitações de pull empilhadas para sua organização

As solicitações de pull empilhadas permitem que os desenvolvedores dividam grandes alterações em uma cadeia de solicitações de pull pequenas e focadas que se baseiam umas nas outras. Essa abordagem pode ajudar sua organização a manter a qualidade da revisão à medida que os desenvolvedores produzem mais código, incluindo com Copilot e outros agentes de codificação.

As solicitações de pull empilhadas não exigem nenhuma configuração ou habilitação. Se sua equipe já usa solicitações de pull, ela pode criar uma pilha hoje. As etapas abaixo ajudam você a preparar seus controles existentes e dar suporte a uma distribuição suave, não ativar um recurso.

Este tutorial ajuda você a decidir se as solicitações de pull empilhadas se encaixam em sua organização, verifique se as fundações estão em vigor, pilota o fluxo de trabalho, dá suporte à adoção e atualiza as ferramentas programáticas. Para obter uma compreensão fundamental das solicitações de pull empilhadas, consulte Sobre solicitações de pull empilhadas.

1. Decida se as solicitações de pull empilhadas são o ajuste certo

Use esta auto check-check rápida antes de investir em uma distribuição:

• Suas equipes produzem um alto volume de código, eles mesmos ou com ou outros Copilot agentes de codificação?
• Suas equipes trabalham em recursos grandes, especialmente dentro de monorepos, que são difíceis de dividir em solicitações de pull independentes?

Se você descrever suas equipes, as solicitações de pull empilhadas poderão ajudá-las a enviar alterações dependentes em unidades menores sem esperar que cada solicitação de pull se mescle antes de iniciar a próxima, desde que seu trabalho atenda a uma restrição: cada solicitação de pull em uma pilha deve estar no mesmo repositório, seguindo uma única cadeia linear de branches. As pilhas não podem incluir bifurcações ou estruturas de ramificação, portanto, equipes que dependem muito de bifurcações para contribuições devem manter essas contribuições fora das pilhas por enquanto.

2. Verifique se as fundações estão em vigor

Cada solicitação de pull em uma pilha é avaliada na base da pilha (normalmente main), em vez do branch que ele direciona diretamente. As regras de proteção de branch existentes ou os conjuntos de regras e fluxos de trabalho de CI se aplicam automaticamente:

• Revisões necessárias, verificações de status necessárias e CODEOWNERS são todas impostas no branch base da pilha para cada solicitação de pull na pilha.
• Um GitHub Actions fluxo de trabalho que dispara em pull_request eventos direcionados ao branch padrão de um repositório é executado para cada solicitação de pull na pilha, portanto, sua configuração de CI existente não precisa ser alterada.
• Os metadados de pilha estão disponíveis em expressões de fluxo de trabalho por meio github.event.pull_request.stackde, se você quiser personalizar o comportamento do fluxo de trabalho especificamente para solicitações de pull empilhadas. Como um fluxo de trabalho é executado uma vez por solicitação de pull em uma pilha, as equipes podem usar esses metadados para limitar trabalhos caros e reduzir o uso de CI. Para obter detalhes, consulte Otimizando a CI para solicitações de pull empilhadas.

Uma adição opcional vale a pena considerar: se os desenvolvedores precisarem reordenar solicitações de pull depois de criar uma pilha sem dissolvê-la, adote a gh stack extensão para GitHub CLI. A reordenação in-loco requer gh stack modify; no site, os GitHub desenvolvedores devem remover as solicitações de pull e recriar a pilha na ordem desejada.

Uma pilha também é fechada automaticamente depois que cada solicitação de pull nela é mesclada. Se uma equipe adicionar novos branches sobre uma pilha mesclada e for executada gh stack submit, a CLI iniciará uma nova pilha com o mesmo branch base. Ele não estende o original. As equipes que desejam continuar trabalhando em um conjunto de alterações devem planejar manter a pilha aberta até que todo o trabalho seja concluído.

Para obter a lista completa de regras e requisitos, consulte Solicitações de pull empilhadas.

3. Piloto com um grupo pequeno

Escolha um pequeno grupo de desenvolvedores que produzem um alto volume de código, por si mesmos ou por meio ou por Copilot outros agentes de codificação. Peça ao grupo para usar um recurso real e representativo para o piloto em vez de um exemplo descartável.

Para criar sua primeira pilha, direcione as pessoas para Início Rápido para solicitações de pull empilhadas. Após o piloto, reúna comentários de desenvolvedores e revisores sobre:

• Como o planejamento de pilha se encaixa em seu fluxo de trabalho existente e se os desenvolvedores precisam de reordenação in-loco, o que requer a gh stack extensão
• Se o fluxo de revisão parecia diferente agora que cada solicitação de pull na pilha carrega suas próprias revisões necessárias e verificações de status
• Quaisquer lacunas de suporte ou documentação em que eles foram executados

4. Implementar e dar suporte à adoção

Após o piloto, compartilhe as diretrizes diárias sobre como criar, revisar, gerenciar e mesclar pilhas com equipes: Solicitações de pull empilhadas.

Conforme observado na etapa 2, recomende a gh stackGitHub CLI extensão quando os desenvolvedores precisarem reordenar uma pilha sem dissolvê-la. As equipes que não usam ferramentas da CLI local podem remover e recriar a pilha na ordem desejada no GitHub site.

As equipes que produzem um alto volume de código gerado por IA, um dos sinais de ajuste da etapa 1, podem encontrar diretrizes sobre como empilhar alterações de agentes de codificação no Código gerado por IA do Stack em solicitações de pull.

5. Atualizar suas ferramentas programáticas

Para sustentar a adoção, examine todas as ferramentas internas, bots ou dashboards que criem, mesclem ou acompanhem solicitações de pull programaticamente e atualize-as para levar em conta as pilhas.

Se sua organização fornecer uma CLI interna ou outra ferramenta de desenvolvedor, você poderá usar a API do Stacks para integrar a criação e o gerenciamento de pilha a essas ferramentas existentes, em vez de exigir que os desenvolvedores adotem gh stack.

Você também pode querer acompanhar a atividade de pilha programaticamente, por exemplo, entre dashboards, bots ou ferramentas internas.

• API REST: cada solicitação de pull retornada pela API inclui um stack objeto quando pertence a uma pilha, mostrando o número, o tamanho da pilha, a posição da solicitação de pull dentro dela e o branch base da pilha. Uma API dedicada do Stacks (GET /repos/{owner}/{repo}/stacks) também lista todas as pilhas em um repositório ou a pilha específica que contém uma determinada solicitação de pull. Consulte APIs e webhooks de solicitações de pull empilhadas.
• Webhooks: o conteúdo do pull_request webhook inclui o mesmo stack objeto sempre que uma solicitação de pull pertence a uma pilha. Uma ação dedicada stacked é acionada quando uma solicitação de pull é adicionada pela primeira vez a uma pilha, para que você possa reagir no momento em que uma pilha se forma.

Em ambos os casos, o stack campo é null para solicitações de pull autônomas, portanto, as integrações existentes que não esperam pilhas continuam funcionando inalteradas.