{"meta":{"title":"Distribuir solicitações de pull empilhadas para sua organização","intro":"Solicitações de pull empilhadas ajudam sua organização a manter a qualidade da revisão à medida que as equipes fornecem grandes alterações em camadas pequenas e revisíveis, mantendo as revisões necessárias e verificações de status em vigor.","product":"Solicitações de pull","breadcrumbs":[{"href":"/pt/pull-requests","title":"Solicitações de pull"},{"href":"/pt/pull-requests/tutorials","title":"Tutoriais"},{"href":"/pt/pull-requests/tutorials/roll-out-stacked-prs","title":"Distribuir PRs empilhadas"}],"documentType":"article"},"body":"# Distribuir solicitações de pull empilhadas para sua organização\n\nSolicitações de pull empilhadas ajudam sua organização a manter a qualidade da revisão à medida que as equipes fornecem grandes alterações em camadas pequenas e revisíveis, mantendo as revisões necessárias e verificações de status em vigor.\n\n> \\[!NOTE]\n> As solicitações de pull empilhadas estão dentro prévia pública e sujeitas a alterações.\n\nAs 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.\n\nAs 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.\n\nEste 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](/pt/pull-requests/get-started/about-stacked-prs).\n\n## 1. Decida se as solicitações de pull empilhadas são o ajuste certo\n\nUse esta auto check-check rápida antes de investir em uma distribuição:\n\n* Suas equipes produzem um alto volume de código, eles mesmos ou com ou outros Copilot agentes de codificação?\n* Suas equipes trabalham em recursos grandes, especialmente dentro de monorepos, que são difíceis de dividir em solicitações de pull independentes?\n\nSe 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.\n\n## 2. Verifique se as fundações estão em vigor\n\nCada 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:\n\n* 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.\n* 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.\n* Os metadados de pilha estão disponíveis em expressões de fluxo de trabalho por meio `github.event.pull_request.stack`de, 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](/pt/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).\n\nUma 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.\n\nUma 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.\n\nPara obter a lista completa de regras e requisitos, consulte [Solicitações de pull empilhadas](/pt/pull-requests/reference/stacked-pull-requests).\n\n## 3. Piloto com um grupo pequeno\n\nEscolha 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.\n\nPara criar sua primeira pilha, direcione as pessoas para [Início Rápido para solicitações de pull empilhadas](/pt/pull-requests/get-started/stacked-prs-quickstart). Após o piloto, reúna comentários de desenvolvedores e revisores sobre:\n\n* 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\n* 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\n* Quaisquer lacunas de suporte ou documentação em que eles foram executados\n\n## 4. Implementar e dar suporte à adoção\n\nApós o piloto, compartilhe as diretrizes diárias sobre como criar, revisar, gerenciar e mesclar pilhas com equipes: [Solicitações de pull empilhadas](/pt/pull-requests/how-tos/stacked-pull-requests).\n\nConforme observado na etapa 2, recomende a `gh stack`GitHub 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.\n\nAs 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](/pt/copilot/tutorials/stack-ai-generated-code-in-pull-requests).\n\n## 5. Atualizar suas ferramentas programáticas\n\nPara 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.\n\nSe 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`.\n\n> \\[!IMPORTANT]\n> Mesclar uma solicitação de pull empilhada requer a API de mesclagem assíncrona. Os pontos de extremidade de mesclagem de solicitação de pull herdados não podem mesclar uma pilha. Se sua organização mesclar solicitações de pull programaticamente, por exemplo, por meio de ferramentas internas ou bots do ChatOps, atualize essa ferramenta para chamar a API de mesclagem assíncrona, que dá suporte a solicitações de pull empilhadas e regulares, antes de distribuir solicitações de pull empilhadas. Consulte [Endpoints da API REST para solicitações de pull](/pt/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).\n\nVocê também pode querer acompanhar a atividade de pilha programaticamente, por exemplo, entre dashboards, bots ou ferramentas internas.\n\n* **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](/pt/pull-requests/reference/stacked-pull-requests-apis-and-webhooks).\n* **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.\n\nEm 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."}