Passo 1 de 7
Entender o papel do pull request
Diferencie publicar uma branch, abrir uma proposta e integrar uma mudança.
Trilha de aprendizado · Nível 4 · Tutorial 1
Você será capaz de propor uma mudança em um repositório com permissão de escrita, escolhendo as branches corretas, explicando a finalidade da proposta e conferindo as alterações antes de abrir o pull request.
Entender o papel do pull request
Diferencie publicar uma branch, abrir uma proposta e integrar uma mudança. 1 min
Publicar a branch e iniciar a proposta
Publique sua branch de trabalho, confirme que ela está no repositório correto e acesse a comparação no GitHub. 2 min
Escolher a origem e o destino
Selecione compare e base para propor as mudanças na direção correta, usando a branch de destino definida pelo projeto. 2 min
Conferir o que entra na proposta
Confira commits, arquivos e diferenças para decidir se a proposta contém apenas as mudanças pretendidas. 3 min
Escrever uma proposta que faça sentido
Prepare um título específico e uma descrição que expliquem o motivo, o escopo e as verificações reais da mudança. 3 min
Abrir e confirmar o pull request
Envie o formulário e confirme que a proposta está aberta, com as branches corretas, sem confundir abertura com integração. 1 min
Aplicação final: apresentar uma mudança completa
Aplique o fluxo em uma proposta real ou simulada e confira se ela está aberta, clara e pronta para revisão. 3 min
Passo 1 de 7
Diferencie publicar uma branch, abrir uma proposta e integrar uma mudança.
Um pull request (PR) é uma proposta para levar alterações de uma branch a outra. No GitHub, ele reúne as mudanças propostas e um espaço para discussão e revisão.
Exemplo
Neste tutorial, você vai acompanhar uma pequena melhoria nas instruções de instalação do README, registrada em uma branch de trabalho. A proposta será entre branches do mesmo repositório, onde você tem permissão de escrita.
Abrir o PR não faz essa integração: são ações distintas.
Dica
Este tutorial termina com uma proposta aberta e disponível para revisão, ainda sem integrar a mudança.
Você publicou a branch com a melhoria no README e abriu um pull request. Só essas duas ações já colocaram a melhoria na branch de destino.
Passo 2 de 7
Publique sua branch de trabalho, confirme que ela está no repositório correto e acesse a comparação no GitHub.
A melhoria na documentação já está registrada em commits na sua branch de trabalho. Para propor essa mudança, a branch com esses commits precisa estar disponível no GitHub.
Publique-a usando o push que você já praticou no tutorial anterior.
No GitHub:
Nesse mesmo repositório, abra a aba Pull requests e clique em New pull request (novo pull request).
Você chegará à tela de comparação entre branches. Esse clique inicia a preparação da proposta, mas ainda não cria o pull request. Pare nessa tela: a escolha das branches será o próximo passo.
Dica
O aviso de branch recém-publicada pode não aparecer. O caminho pela aba Pull requests funciona mesmo sem ele.
Sua melhoria na documentação está commitada, mas a branch ainda não foi publicada. Ordene as ações para chegar à comparação no GitHub.
Passo 3 de 7
Selecione compare e base para propor as mudanças na direção correta, usando a branch de destino definida pelo projeto.
Na comparação do GitHub, cada seletor tem um papel:
Leia sempre: alterações de compare para base. Neste tutorial, escolha as duas branches no mesmo repositório.
Dica
Não mantenha main como base só porque ela apareceu selecionada. Use a branch de destino indicada pelo projeto. Se não souber qual é, confirme a orientação antes de continuar.
Você melhorou as instruções de instalação na branch docs/instalacao. O projeto orienta que essa mudança seja proposta para develop. As duas branches estão publicadas no mesmo repositório.
Associe os campos e o sentido da proposta aos valores corretos.
Toque em um item e depois no par correspondente.
Na tela de comparação que você abriu:
No cenário do exercício, os seletores devem ficar como base: develop e compare: docs/instalacao.
Dica
Embora base apareça antes de compare na interface, a proposta vai de compare para base. Siga os rótulos, não apenas a posição dos seletores.
Passo 4 de 7
Confira commits, arquivos e diferenças para decidir se a proposta contém apenas as mudanças pretendidas.
Nossa melhoria de documentação tem um limite claro: esclarecer, no README, em que ordem executar os passos de instalação, sem mudar outras seções. Antes de abrir o pull request, confira se a comparação corresponde a esse objetivo.
Abaixo dos seletores de branches, confira:
Dica
Interrompa a abertura. Primeiro, confirme se base e compare são as branches pretendidas. Depois, confira o escopo das alterações. Só avance quando entender a divergência e a comparação estiver coerente com o objetivo.
Exemplo
Objetivo: esclarecer a ordem dos passos de instalação no README.
Commits incluídos:
Arquivos e diferenças:
README.md: acrescenta a orientação de seguir a ordem apresentada.src/config.js: altera o tempo limite de conexão.Você não pretendia propor uma alteração de configuração. Como deve proceder?
Imagine outra comparação: há apenas o commit “Esclarece instalação” e o arquivo README.md. Isso ainda não basta. Veja o trecho de diferenças:
--- a/README.md
+++ b/README.md
@@ -12,4 +12,1 @@
-Execute os comandos abaixo.
+Execute os comandos abaixo, na ordem apresentada.
-
-## Como contribuir
-Leia CONTRIBUTING.md antes de enviar sugestões.Dica
A orientação de instalação foi esclarecida, mas a seção “Como contribuir” também foi removida. Essa exclusão está fora do objetivo definido. Mesmo com o arquivo e a mensagem de commit esperados, é necessário interromper e investigar.
Exemplo
Considere agora este cenário:
README.md.--- a/README.md
+++ b/README.md
@@ -12 +12 @@
-Execute os comandos abaixo.
+Execute os comandos abaixo, na ordem apresentada.O conjunto de alterações corresponde ao objetivo de esclarecer a ordem da instalação. Você pode seguir para preparar a apresentação da proposta.
Passo 5 de 7
Prepare um título específico e uma descrição que expliquem o motivo, o escopo e as verificações reais da mudança.
Depois de conferir as alterações, clique em Create pull request na tela de comparação. Esse primeiro clique abre o formulário para preencher título e descrição; ainda não cria a proposta.
O envio do formulário usa outro botão com o mesmo rótulo, Create pull request. Essa ação efetivamente cria a proposta e ficará para o próximo passo.
O título deve permitir que alguém entenda a mudança sem abrir os arquivos. Uma boa combinação é ação + o que foi alterado + onde, quando isso ajudar. Evite títulos genéricos como “Ajustes” e não prometa mais do que as alterações entregam.
A única alteração foi corrigir, no README, um link quebrado para o guia de instalação. Nenhum código foi modificado. Qual título é mais adequado?
A descrição deve explicar o conjunto da mudança, não apenas repetir a lista de commits.
Exemplo
Motivo: o link quebrado no README impedia o acesso ao guia de instalação.
Escopo: corrigi somente o endereço desse link. Não alterei o guia nem o código.
Conferência: cliquei no link no README exibido no GitHub e confirmei que ele abre o guia esperado. Não executei testes automatizados.
Dica
Uma conferência manual também conta, mas diga exatamente o que verificou. Visualizar o README não prova que as instruções funcionam. Informe verificações não realizadas em vez de escrever “Tudo testado”.
Escreva um título específico e uma descrição com motivo, escopo e conferência. Use apenas os fatos apresentados.
Escreva pelo menos 80 caracteres (0/80).
Passo 6 de 7
Envie o formulário e confirme que a proposta está aberta, com as branches corretas, sem confundir abertura com integração.
Com as branches selecionadas, as alterações conferidas e o título e a descrição preenchidos, clique em Create pull request (Criar pull request) no formulário.
É esse envio que cria o pull request. Apenas preencher os campos não abre a proposta. Aguarde o carregamento da página do pull request.
No topo da página, localize o título, o número da proposta e o estado Open (aberto). Confira também se a origem e o destino exibidos são as branches que você escolheu.
Exemplo
Neste exemplo, o projeto definiu develop como destino:
docs/instalacaodevelopSe esses dados correspondem à proposta planejada, a abertura está confirmada. Ela está disponível para revisão; sua criação não integrou as mudanças em develop. Pare aqui, sem acionar a integração.
Após enviar o formulário, você encontra o título esperado, um número, o estado aberto e as branches corretas na página. O que isso confirma?
Passo 7 de 7
Aplique o fluxo em uma proposta real ou simulada e confira se ela está aberta, clara e pronta para revisão.
Use um repositório de prática com permissão de escrita e uma melhoria na documentação já registrada em commits. Se você já abriu a proposta durante o tutorial, confira a existente, sem criar outra. Sem acesso ao GitHub agora? Faça uma simulação com o cenário abaixo.
Exemplo
O README não informa onde salvar imagens. A branch local docs/imagens contém um commit que altera apenas README.md, acrescentando a indicação da pasta assets/imagens/. O destino definido pelo projeto é develop.
Neste cenário, o texto e o diff foram lidos, e o caminho foi conferido na estrutura do projeto. Não foram executados testes.
Dica
Publique a branch → inicie a comparação pela área de pull requests → selecione compare e base no mesmo repositório → confira commits, arquivos e diferenças → escreva título e descrição → envie o formulário e confirme a abertura. Se aparecer conteúdo inesperado, pare e verifique as branches e o escopo.
Registre como confirmou a publicação da branch, quais são compare e base e o que encontrou nos commits, arquivos e diferenças. Inclua o título e a descrição da proposta, com motivo, escopo e conferência realizada.
Finalize dizendo como confirmou a abertura. Na simulação, descreva as ações esperadas, sem afirmar que as executou.
Escreva pelo menos 100 caracteres (0/100).
As branches e as alterações estão corretas, e o título e a descrição estão preenchidos. Mesmo sem enviar o formulário, o pull request já está aberto e disponível para revisão.
Resumo
Antes de encerrar a prática, confira:
Parabéns! Você concluiu: Abrir um pull request com uma proposta clara
O resultado esperado é uma proposta aberta, clara e disponível para revisão — ainda não integrada. No próximo tutorial, você aprenderá a revisar e atualizar um pull request.
Milhares de cursos online em vídeo, ebooks e áudiobooks.
Para testar seus conhecimentos no decorrer dos cursos online
Gerado diretamente na galeria de fotos do seu celular e enviado ao seu e-mail
Baixe nosso aplicativo pelo QR Code ou pelos links abaixo:.
Leve o conhecimento no seu bolso.
Baixe o aplicativo Cursa.
São centenas de Cursos gratuitos a disposição, com Certificado de conclusão gratuito que é salvo em sua galeria de imagens do celular.
Baixe o app para ter acesso ao Certificado de conclusão de Curso Gratuitamente.
+ de 10 milhões
de alunos
Certificado grátis e
válido em todo o Brasil
60 mil exercícios
gratuitos
4,8/5 classificação
nas lojas de apps
Cursos gratuitos em
vídeo, ebooks e audiobooks
