# Solicitações de pull

Propor, revisar e mesclar alterações de código usando solicitações de pull para colaborar efetivamente e manter a qualidade do código.

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.

<a href="https://github.com/pulls?ref_product=github&ref_type=engagement&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
<span>Exibir suas solicitações de pull</span><svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>

## Trabalhar 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](/pt/enterprise-server@3.17/pull-requests/how-tos/create-pull-requests/changing-the-stage-of-a-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](/pt/enterprise-server@3.17/actions/reference/workflows-and-actions/events-that-trigger-workflows#how-the-merge-branch-affects-your-workflow).

## 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.

> \[!TIP]
> 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](https://opensource.guide/), 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](https://skills.github.com/) 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.

## Leitura adicional

* [Como criar uma solicitação de pull](/pt/enterprise-server@3.17/pull-requests/how-tos/create-pull-requests/creating-a-pull-request)
* [Branches](/pt/enterprise-server@3.17/pull-requests/reference/branches)
* [Fazer comentários em uma pull request](/pt/enterprise-server@3.17/pull-requests/how-tos/review-pull-requests/commenting-on-a-pull-request)
* [Creating a pull request from a fork](/pt/enterprise-server@3.17/pull-requests/how-tos/create-pull-requests/creating-a-pull-request-from-a-fork)
* [Allowing changes to a pull request branch created from a fork](/pt/enterprise-server@3.17/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)