Solicitações de pull são propostas para mesclar alterações de código em um projeto. Uma solicitação de pull é GitHubo principal recurso de colaboração, permitindo que você discuta e examine as alterações antes de mesclá-las. Isso ajuda as equipes a trabalhar em conjunto, capturar problemas antecipadamente e manter a qualidade do código.
Exibir suas solicitações de pullTrabalhar com solicitações de pull
Um pull request reúne o contexto de que os revisores precisam para entender uma alteração. Este contexto é organizado em abas:
- A aba Conversa mostra a descrição, a linha do tempo, os comentários e as revisões.
- A aba Commits mostra como o branch da solicitação de pull mudou ao longo do tempo.
- A guia Verificações mostra testes automatizados, builds e outras validações.
- A aba Arquivos alterados mostra as diferenças que os revisores usam para entender as alterações propostas.
- A guia Descobertas mostra os resultados automatizados de revisão de código, como alertas de verificação de código, para as alterações propostas.
Além das abas, o status da mesclagem destaca bloqueios, falta de aprovações e outros requisitos antes de mesclar. Isso aparece no cabeçalho da pull request e na caixa de mesclagem.
Juntas, essas visualizações ajudam autores e revisores a discutir a alteração, acompanhar o feedback e decidir quando o pull request está pronto para ser mesclado.
Rascunhos de solicitações de pull
Ao criar uma solicitação de pull, você pode optar por torná-la um rascunho. As solicitações de pull em rascunho não podem ser mescladas e os proprietários do código não são solicitados automaticamente a revisá-las. Rascunhos são úteis quando você deseja compartilhar o trabalho em andamento sem solicitar formalmente revisões.
Quando você estiver pronto para receber feedback sobre seu pull request, você poderá marcar seu rascunho de pull request como pronto para revisão. Marcar um pull request como pronto para revisão irá solicitar revisões de qualquer proprietário de código. Você pode converter uma solicitação de pull em um rascunho a qualquer momento. Consulte Alterar a fase de uma pull request.
Refs de pull request e ramificações de merge
Quando você abre uma solicitação de pull, GitHub cria referências temporárias do Git que apontam para o branch principal da solicitação de pull e, quando possível, para um resultado de mesclagem simulado. Essas refs ajudam GitHub e as integrações a avaliar o pull request sem alterar a branch base.
Para a maioria dos colaboradores, esses refs permanecem em segundo plano. Elas são mais relevantes quando você está criando automação, depurando o comportamento de CI ou buscando o estado da solicitação de pull localmente. Para obter informações sobre como GitHub Actions usa o branch de mesclagem, consulte Eventos que disparam fluxos de trabalho.
Diferenças entre commits em páginas de comparação e pull request
Páginas de comparação e páginas de pull request podem calcular arquivos alterados a partir de diferentes bases de mesclagem. Como resultado, as mesmas ramificações às vezes podem mostrar diferenças diferentes em cada lugar.
Isso geralmente acontece quando o ramo base foi alterado desde que o pull request foi criado. As páginas de pull request se concentram no que o pull request introduziu, enquanto as páginas de comparação mostram a comparação atual entre duas referências.
Modelos de desenvolvimento colaborativos
O modo como você usa pull requests depende do tipo de modelo de desenvolvimento usado no projeto. Você pode usar o modelo de fork e pull ou o modelo de repositório compartilhado.
Modelo de bifurcação e pull
No modelo de fork e pull, qualquer pessoa pode fazer fork de um repositório existente ("upstream") se tiver acesso de leitura e se o proprietário do repositório upstream permitir. Lembre-se de que uma bifurcação e seu upstream compartilham os mesmos dados do Git. Isso significa que todo o conteúdo carregado em um fork pode ser acessado a partir do upstream e de todos os outros forks desse upstream.
Você não precisa de permissão do repositório upstream para fazer push em um fork que você criou. Opcionalmente, você pode permitir que qualquer pessoa com acesso push ao repositório upstream faça alterações no branch de pull request. Esse modelo é popular entre projetos de software livre porque reduz o atrito para novos colaboradores e permite que as pessoas trabalhem de forma independente sem coordenação inicial.
Dica
Para obter mais informações sobre o código aberto, especificamente como criar e expandir um projeto de código aberto, criamos os Guias de Código Aberto, que ajudarão você a promover uma comunidade de código aberto benéfica.Você também pode fazer um curso gratuito de GitHub Skills sobre como manter comunidades de código aberto.
Modelo de repositório compartilhado
No modelo de repositório compartilhado, os colaboradores têm acesso por push a um único repositório compartilhado e criam branches de tópico quando precisam fazer alterações. As solicitações pull são úteis nesse modelo porque iniciam a revisão de código e a discussão geral sobre um conjunto de alterações antes que as alterações sejam mescladas no branch de desenvolvimento principal. Esse modelo é mais comum com pequenas equipes e organizações colaborando em projetos privados.