Trilha de aprendizado · Nível 4 · Tutorial 3

Integrar um pull request e atualizar a branch principal

Você será capaz de concluir uma proposta revisada pela interface do GitHub quando houver permissão, respeitar os bloqueios de integração e atualizar a branch principal local com a mudança integrada.

Nível: Iniciante
Duração: 14 min
7 passos

Começar tutorial Voltar para a trilha

O que você vai percorrer

Conferir o destino e a permissão para integrar Reconheça o que a aprovação significa e confira o repositório, a branch de destino e a autorização antes de integrar. 2 min
Identificar e respeitar os bloqueios Leia as pendências do painel de integração e decida quando aguardar, solicitar ajustes ou procurar o responsável pelo repositório. 2 min
Integrar pelo GitHub com um commit de merge Integre um pull request liberado no repositório de prática, escolhendo a criação de um commit de merge e conferindo os dados antes de confirmar. 2 min
Confirmar a integração, não apenas o fechamento Diferencie uma proposta integrada de uma proposta apenas fechada e confira o registro do merge no GitHub. 1 min
Trazer a integração para a branch principal local Atualize a branch principal no computador com a integração feita no GitHub, respeitando as condições de segurança da prática. 2 min
Conferir os arquivos e o histórico local Valide a atualização da branch principal local reunindo evidências do estado, do conteúdo dos arquivos e do commit de merge. 2 min
Aplicação final: concluir o fluxo colaborativo Respeite um bloqueio de integração e registre evidências de que uma proposta liberada chegou à branch principal local. 3 min

O que você vai aprender

Verificar a branch de destino, as permissões e os requisitos apresentados pelo GitHub antes da integração.
Reconhecer quando aprovações pendentes, verificações automáticas ou conflitos impedem a integração, sem tentar contornar esses bloqueios.
Integrar o pull request pela interface do GitHub em um repositório de prática que permita criar um commit de merge.
Confirmar que a proposta foi integrada, distinguindo esse resultado de um fechamento sem integração.
Sincronizar a branch principal local pelo fluxo já aprendido e verificar a presença da mudança nos arquivos e no histórico.

Antes de começar

Revisar e atualizar um pull request
Integrar branches locais com merge
Sincronizar alterações com fetch, pull e push

Passo 1 de 7

Conferir o destino e a permissão para integrar

Reconheça o que a aprovação significa e confira o repositório, a branch de destino e a autorização antes de integrar.

Aprovado não significa integrado

Retome o pull request revisado no tutorial anterior.

Uma aprovação registra uma avaliação favorável da proposta. Ela não incorpora, por si só, as mudanças à branch de destino.

Integrar é uma ação separada. Antes dela, você precisa conferir onde a mudança vai entrar e se tem autorização para realizar essa ação.

O que a aprovação garante?

A aprovação de uma revisão, por si só, já atualiza a branch de destino com as mudanças do pull request.

VerdadeiroFalso

Confira o destino e a autorização

Onde a mudança vai entrar?

Na página do pull request, confira:

Repositório: o proprietário ou a organização e o nome do projeto são os esperados?
Destino: a branch indicada como base corresponde à branch principal definida pelo projeto?

Use o nome real dessa branch. Não presuma que ela se chama main.

Dica

Escrita não é autorização irrestrita

Confirme se sua conta pode integrar conforme as regras do repositório. Ter permissão de escrita não garante que a integração esteja liberada. Se houver dúvida sobre sua autorização, consulte o responsável antes de prosseguir.

Você pode prosseguir?

Você está no repositório correto. A branch principal do projeto se chama principal, mas o pull request aprovado aponta para main. Sua conta tem permissão de escrita.

Qual é a decisão adequada?

Integrar em `main`, pois a aprovação confirma que todos os dados estão corretos.Não integrar ainda: o destino está incorreto e a autorização também precisa ser conferida.Conferir apenas o destino, pois a permissão de escrita já garante a autorização para integrar.

Passo 2 de 7

Identificar e respeitar os bloqueios

Leia as pendências do painel de integração e decida quando aguardar, solicitar ajustes ou procurar o responsável pelo repositório.

Leia o motivo do bloqueio

O painel indica o que falta

Na página do pull request, localize o painel de integração, na parte inferior da conversa. Leia os requisitos e as pendências: não avalie apenas se o botão está disponível. As exigências dependem das regras do repositório.

Pendências de revisão e execução

Falta aprovação obrigatória: solicite a revisão a um revisor e aguarde.
Há solicitação de alterações bloqueando a integração: encaminhe os ajustes ao autor e, depois, peça nova avaliação ao revisor.
Verificação automática obrigatória em andamento: aguarde o resultado. Testes e outras verificações ainda em execução não contam como aprovados.

O que fazer com este painel?

Exemplo

Painel simulado — mensagens resumidas

Aprovações obrigatórias: atendidas.
Verificações obrigatórias: 1 em andamento.
Conflitos: nenhum identificado.
Integração: bloqueada.

Escolha o próximo encaminhamento

Qual é a ação adequada diante desse painel?

Aguardar a verificação terminar e conferir o resultado.Pedir outra aprovação para substituir a verificação pendente.Pedir ao responsável que ignore a verificação, pois não há conflitos.

Quando aguardar não basta

Falhas e conflitos exigem atenção

Verificação obrigatória com falha: encaminhe o resultado ao autor para investigar e providenciar os ajustes necessários. Apenas esperar não resolve a falha.
Conflitos entre as branches: o GitHub não consegue combinar as mudanças automaticamente. Avise o autor para que providencie a resolução antes de uma nova avaliação.

Dica

Dúvida sobre permissão ou regra?

Interrompa a tentativa e procure o responsável pelo repositório. Informe qual pull request está avaliando e a mensagem exibida no painel.

Atenção

Não contorne o bloqueio

Não tente forçar a integração nem ignorar requisitos obrigatórios. Depois que uma pendência for tratada, confira novamente o painel completo.

Encaminhe cada pendência

Quem pode ajudar?

Associe cada aviso resumido do painel ao encaminhamento adequado.

Toque em um item e depois no par correspondente.

Passo 3 de 7

Integrar pelo GitHub com um commit de merge

Integre um pull request liberado no repositório de prática, escolhendo a criação de um commit de merge e conferindo os dados antes de confirmar.

Escolha o método de integração

Prepare a integração

No pull request revisado do repositório de prática, prossiga apenas com permissão adequada e requisitos atendidos.

No painel de integração, abra o seletor ao lado do botão, se houver, e escolha Create a merge commit (criar um commit de merge). Se houver apenas um método disponível, confira se ele cria um commit de merge. Não presuma que a opção inicialmente exibida seja a correta.

Atenção

A opção necessária não aparece?

Se a criação de um commit de merge estiver indisponível, interrompa a prática e consulte o responsável pelo repositório. Não escolha outro método nem altere regras para continuar.

Botão liberado, método correto?

Confira antes de clicar

O botão de integração está habilitado. Isso basta para garantir que a integração criará um commit de merge.

VerdadeiroFalso

Confira e confirme no GitHub

Execute no repositório de prática

Com o método correto selecionado, clique em Merge pull request (integrar o pull request) para abrir a confirmação.
Confira na página o repositório, o número do pull request e as branches de origem e destino. O destino deve ser a branch principal pelo nome real.
Revise a mensagem apresentada para o commit de merge.
Se tudo corresponder à proposta revisada, clique em Confirm merge (confirmar integração). Se encontrar alguma divergência, pare antes de confirmar.

Dica

A mudança acontece no GitHub

A integração bem-sucedida cria o commit de merge na branch de destino do GitHub. O repositório no seu computador não é atualizado automaticamente.

Registre sua prática

Qual opção e qual destino?

Após executar a integração, registre a opção utilizada e o nome exato da branch que recebeu o commit de merge no GitHub. Se precisou interromper, informe o motivo e quem deve ser consultado.

Escreva pelo menos 15 caracteres (0/15).

Passo 4 de 7

Confirmar a integração, não apenas o fechamento

Diferencie uma proposta integrada de uma proposta apenas fechada e confira o registro do merge no GitHub.

Dois encerramentos, resultados diferentes

Leia o estado do pull request

Depois da confirmação, confira o estado na página do pull request:

Merged (integrado): a proposta foi incorporada à branch de destino.
Closed (fechado), sem merge: a proposta foi encerrada sem executar sua integração.

Encerrar a discussão de uma proposta não é o mesmo que integrar suas mudanças.

Dica

Sumir da lista não comprova o merge

Tanto um pull request integrado quanto um fechado sem integração deixam a lista de propostas abertas. Abra a página da proposta para verificar o resultado.

O que cada evidência permite concluir?

Relacione a evidência ao resultado

Associe cada situação à conclusão que ela permite tirar.

Toque em um item e depois no par correspondente.

Confira o registro e o commit

Verifique o pull request da prática

No GitHub, faça esta conferência:

Confirme que a página do pull request mostra Merged (integrado).
Na linha do tempo da conversa, localize o registro da integração e confira a branch de destino indicada.
Clique no identificador do commit de merge associado ao registro. Consulte também o histórico da branch de destino e confirme a presença desse mesmo commit.

Assim, você identifica não apenas que a proposta foi integrada, mas também onde a integração ficou registrada.

Passo 5 de 7

Trazer a integração para a branch principal local

Atualize a branch principal no computador com a integração feita no GitHub, respeitando as condições de segurança da prática.

Prepare o repositório local

Integrado no GitHub, ainda não no computador

Você já confirmou a integração do pull request. Agora, aplique o fluxo de sincronização conhecido para trazer essa mudança à branch principal local.

Condições da prática

Use o repositório de prática com origin apontando para o repositório correto. A branch principal local deve existir, ter o acompanhamento da branch correspondente em origin configurado e não conter commits locais exclusivos.

Antes de trocar de branch

No terminal, dentro da pasta do repositório, confira o estado do trabalho:

bash

git status

Atenção

Não avance com uma situação inesperada

Se houver alterações locais, pare antes da troca e preserve o trabalho. Durante a prática, erros, divergências ou conflitos inesperados também exigem uma pausa para avaliação. Não descarte trabalho nem force operações; peça orientação se necessário.

Atualize a branch principal correta

Use o nome real

Nos comandos abaixo, a branch principal se chama main. Se o nome no seu repositório for outro, substitua main tanto em git switch quanto em origin/main. Execute um comando por vez e confira o resultado antes de continuar.

Troque, busque e confira

bash

git switch main
git fetch origin
git status

Atenção

Faça uma pausa antes do merge

Confirme no status que você está na branch principal. Após o fetch, estar atrás de origin/main é esperado neste cenário; ter commits locais à frente ou divergência não é. Nesses casos, interrompa a prática antes do merge.

Integre na branch local

O fetch atualizou origin/main, mas não incorporou a mudança aos arquivos locais. Com as condições atendidas e estando em main, execute:

bash

git merge origin/main

Organize a sincronização

Do merge remoto à atualização local

O pull request foi integrado em main, mas você ainda está na branch de trabalho local. Ordene o roteiro praticado. Considere que todas as conferências permitem continuar.

Buscar as atualizações com git fetch origin.
Integrar a referência atualizada com git merge origin/main.
Executar git status novamente e conferir a branch e sua relação com origin/main.
Executar git status e conferir o trabalho antes da troca.
Trocar para a branch principal com git switch main.

Passo 6 de 7

Conferir os arquivos e o histórico local

Valide a atualização da branch principal local reunindo evidências do estado, do conteúdo dos arquivos e do commit de merge.

Confira a mudança no arquivo

Após a sincronização, execute o comando abaixo e confirme que você está na branch principal local, usando o nome real dela. Observe também se há alterações não commitadas.

bash

git status

Exemplo

Procure o conteúdo esperado

Abra no editor o arquivo alterado pelo pull request. Por exemplo: se a proposta acrescentou ao README.md a frase “Execute os testes antes de enviar alterações.”, confira se esse trecho está no arquivo local. Apenas encontrar o arquivo não basta.

Estado limpo é suficiente?

Estar na branch principal local com o estado de trabalho limpo já comprova que a mudança do pull request está presente.

VerdadeiroFalso

Relacione o histórico local ao pull request

Na branch principal local, consulte o histórico. Localize o commit de merge e compare seu identificador com o registrado na integração do pull request no GitHub. O identificador abreviado deve coincidir com o início do identificador completo.

Histórico da branch atual

bash

git log --oneline --graph --decorate

Dica

Aqui, não usamos --all: queremos conferir o histórico da branch atual, sem incluir commits que estejam apenas em outras branches. Uma mensagem parecida não substitui a comparação do identificador.

Registre suas evidências

O que você confirmou no computador?

No repositório de prática, registre:

O nome da branch principal local e o resultado do git status.
O arquivo e o trecho que comprovam a mudança.
O identificador do commit de merge encontrado no histórico e sua correspondência com o pull request no GitHub.

Se alguma evidência estiver ausente, informe o que falta confirmar.

Escreva pelo menos 40 caracteres (0/40).

Passo 7 de 7

Aplicação final: concluir o fluxo colaborativo

Respeite um bloqueio de integração e registre evidências de que uma proposta liberada chegou à branch principal local.

Sua missão final

Conclua com evidências

Conclua o pull request revisado no repositório de prática e comprove a atualização da branch principal local.

Se você já integrou e sincronizou nas etapas anteriores, apenas confira e registre o resultado. Não tente integrar o mesmo pull request novamente.

Dica

Condições para executar

Use uma proposta liberada, com criação de commit de merge habilitada. A principal local deve existir, ter acompanhamento configurado e não possuir commits exclusivos. Diante de alterações locais, divergências ou conflitos inesperados, interrompa para avaliar: não descarte trabalho nem force operações.

Primeiro, uma decisão

A aprovação é suficiente?

O destino está correto, você tem permissão de escrita e o pull request recebeu aprovação. Porém, o painel mostra uma verificação automática obrigatória com falha. O que fazer?

Prosseguir com a integração, pois a proposta já foi aprovada.Interromper e pedir ao autor que investigue a falha antes de reavaliar os requisitos.Obter mais uma aprovação e integrar sem tratar a falha.Fechar o pull request e considerar a mudança incorporada.

Execute e registre

Da liberação à conferência local

Confira repositório, destino, autorização e requisitos. Se liberado, selecione a opção de criar um commit de merge, confira os dados e confirme.
Confirme o estado integrado e o commit de merge associado no GitHub.
Execute git status. Com o trabalho limpo e nas condições da prática, mude para a principal pelo nome real e sincronize pelo fluxo conhecido de busca seguida de integração.
Confira o estado local, a mudança nos arquivos e o commit de merge no histórico.

Qual é a evidência da conclusão?

Registre os dados reais da sua prática nos campos do roteiro abaixo. Se houver bloqueio, informe a pendência e a quem encaminhou; não declare o fluxo concluído.

Escreva pelo menos 80 caracteres (0/80).

Feche o ciclo com segurança

Resumo

Seu critério de conclusão

Sem liberação, interrompa: ajustes ao autor, revisões aos revisores e dúvidas de permissão ao responsável pelo repositório. Não contorne bloqueios.
No GitHub, confirme o estado integrado e o commit de merge. Apenas sair da lista de propostas abertas não comprova integração.
Na principal local, confira estado, conteúdo e histórico. Trabalho limpo, sozinho, não comprova que a mudança chegou.