Uma pilha é uma série de solicitações de pull no mesmo repositório em que cada solicitação de pull direciona o branch da solicitação de pull abaixo dela, formando uma cadeia ordenada que cai em um único branch, normalmente seu branch principal. Em vez de uma solicitação de pull grande, você obtém um conjunto de solicitações de pull menores. Como cada solicitação de pull tem sua própria diferença de foco, os colegas de equipe podem examinar e aprovar cada camada de forma independente.
Cada pull request em uma pilha é avaliado em relação às regras para a base da pilha — normalmente main — independentemente de qual ramificação ele tem como destino direto. Isso significa que os pull requests no meio da pilha são mantidos no mesmo padrão que o pull request da base.
Observação
- As solicitações de pull empilhadas exigem que todos os branches estejam no mesmo repositório. Não há suporte para pilhas entre bifurcações.
- Não há suporte para solicitações de pull empilhadas.GitHub Desktop
Disponibilidade de pull requests empilhados
A gh stackGitHub CLI extensão gerencia o fluxo de trabalho de desenvolvimento local. Ele cria e rastreia branches na ordem de dependência correta, mantém branches rebased, envia branches, cria e vincula pull requests e navega entre camadas.
GitHub CLI não é necessário. As operações Git subjacentes são padrão, e você pode criar pilhas a partir do site GitHub.
Se você usar outras ferramentas, como Jujutsu ou Sapling, para gerenciar e enviar por push suas branches locais, você ainda poderá usar GitHub CLI ou o site GitHub para abrir uma pilha de pull requests dessas branches. Consulte Usar outras ferramentas com pull requests empilhados.
Ramificações principais para pull requests empilhados
O trunk de uma pilha é o branch base da solicitação de pull inferior. Todas as outras pull requests na pilha são construídas sobre ela. O trunk segue o branch padrão do seu repositório, como main, por exemplo, mas pode ser qualquer branch, como um branch de lançamento ou um branch de recurso de longa duração.
Para definir o tronco SIP:
- Em GitHub CLI passe a opção
--base BRANCHpara o comandogh stack init, (por exemplo,gh stack init --base release auth-layer). - No site GitHub, crie a pull request inferior contra qualquer branch que você queira usar como tronco. O restante da pilha se baseia nela.
As regras de proteção de ramificação, as verificações necessárias e a CI são avaliadas em relação ao trunk para o qual a stack aponta, não apenas em relação ao branch padrão.
Proteções de branch e verificações obrigatórias
Todos os seguintes são avaliados como se cada pull request tivesse como destino a base da pilha, não o branch diretamente abaixo dela:
| Regra | Como é avaliado |
|---|---|
| Revisões obrigatórias | Avaliado em relação à base da pilha. |
| Verificações de status necessárias | Avaliado com base na base da stack. |
| CODEOWNERS | Avaliado a partir da base de pilha. As alterações em CODEOWNERS em uma solicitação de pull inferior não afetam as solicitações de pull acima dela. |
| Fluxos de trabalho de verificação de código | Avaliado em relação à base de pilha. |
GitHub Actions
GitHub Os fluxos de trabalho do Actions são acionados como se cada pull request na pilha tivesse como destino a base da pilha. Um fluxo de trabalho configurado para ser executado em eventos pull_request direcionados a main é executado para cada solicitação de pull na pilha, não apenas para a solicitação na parte inferior, portanto, nenhuma alteração no fluxo de trabalho é necessária.
Metadados de pilha, como o branch base da pilha, estão disponíveis em expressões de fluxo de trabalho por meio de github.event.pull_request.stack. Essa propriedade só está presente quando o pull request pertence a uma stack.
Para obter o conjunto completo de campos de metadados e padrões para reduzir o uso redundante de CI, consulte Otimizando a CI para pull requests empilhadas.
Rebase
Quando uma rebase estiver disponível ou necessária, a caixa de mesclagem indicará isso exibindo um botão Rebase stack. Por exemplo, isso pode acontecer quando alterações em uma solicitação de pull tornam a pilha não linear. Quando o pull request inferior é mesclado, um rebase ocorre automaticamente e você normalmente não precisará fazer rebase manualmente.
Quando uma pilha é rebaseada, você pode esperar o seguinte:
- A rebasing da pilha gera commits assinados.
- Fazer rebasing de uma pilha não conta como um commit novo e revisável se o diff não mudar. As aprovações são mantidas nessa situação, mesmo quando a regra Ignorar aprovações obsoletas de pull request quando novos commits forem enviados está habilitada.
Requisitos de mesclagem
Antes que uma pull request em uma pilha possa fazer merge, todas as condições a seguir devem ser atendidas:
- A solicitação de pull atende a todos os requisitos de proteção de branch para a base da stack, incluindo revisões necessárias, verificações de status necessárias e aprovações de CODEOWNERS.
- Todas as pull requests abaixo dela na pilha também atendem a esses requisitos.
- A pilha tem um histórico totalmente linear entre suas ramificações.
Por exemplo, na pilha main ← PR1 ← PR2 ← PR3, mesclar PR #3 requer PR #1 e PR #2 para também passar verificações, ter revisões necessárias e atender a todas as regras de proteção de branch.
Observação
As solicitações de pull empilhadas dão suporte à mesclagem com regras de bypass, mas somente a solicitação de pull inferior pode ser mesclada dessa maneira. Não é possível mesclar toda a pilha com regras de bypass. Confira Criar conjuntos de regras para um repositório
Métodos de mesclagem
As pilhas suportam os três métodos de mesclagem. Em cada caso, os pull requests são mesclados como uma única operação atômica:
- Commit de mesclagem cria um commit de mesclagem para cada pull request que está sendo mesclado, preservando o histórico completo de commits de cada pull request.
- Squash cria um commit limpo e compactado por pull request. A mesclagem
nde pull requests criancommits compactados no branch base. - Rebase reaplica os commits de cada pull request no branch base, criando um histórico linear sem commits de merge.
Mesclar por meio de uma fila de mesclagem
Stacks dão suporte total a filas de merge. Todos os pull requests na pilha são adicionados à fila na ordem correta. Se uma solicitação de pull for removida ou ejetada da fila, todas as solicitações de pull acima dela na pilha também serão removidas.
Observação
Para manter uma pilha unida, a fila de mesclagem permite que o grupo de mesclagem exceda seu tamanho máximo configurado em até 50%. Se a pilha for muito grande para caber dentro desse buffer, ela será colocada automaticamente no próximo grupo de mesclagem como uma única unidade.
Histórico linear
Um histórico totalmente linear entre cada branch na pilha é um requisito estrito para mesclagem. Uma pilha pode perder seu histórico linear quando as alterações são enviadas por push para um branch inferior ou quando o trunk avança.
Para restaurar um histórico linear, execute uma rebase em cascata:
- Na CLI — executar
gh stack rebasee, em seguida, efetuar push comgh stack push. - Pelo GitHub site — clique em Rebase stack na caixa de mesclagem para disparar uma rebase em cascata do lado do servidor.
Para obter instruções, consulte Gerenciando solicitações de pull empilhadas.