Pull request no GitHub: abrir, revisar e fazer o merge

Pull request é um pedido de integração entre branches com espaço para contexto, revisão e verificações. Você prepara commits com Git, envia a branch e usa o GitHub para discutir o diff. Depois, a estratégia escolhida determina o histórico que sobra.

Esta produção não abriu, aprovou nem mesclou um PR externo. Os comandos foram executados com bare local e três históricos equivalentes foram gerados no Git. Os passos de interface seguem a documentação oficial do GitHub.

git --no-pager log --oneline -3

O pedido começa antes do botão verde

Uma feature revisável tem escopo claro e commits que contam a mudança. No sandbox, a busca ganhou código e documentação separados. Antes de publicar, rode testes, leia git diff main...HEAD e remova arquivos acidentais.

git diff --stat main...HEAD

Os três pontos comparam a ponta da branch ao ancestral comum. Isso representa melhor o conteúdo proposto do que comparar duas working trees ao acaso.

Envie a branch e confirme o upstream

git push -u origin feat/busca

No GitHub, escolha main como base e feat/busca como compare. O bare comprova o envio da branch, mas não possui tela, comentários ou proteção. Abra o PR numa conta e repositório sob sua responsabilidade.

git branch -vv

Uma descrição permite revisar sem adivinhação

Título responde o resultado: “Adiciona busca de livros por título”. A descrição explica problema, solução, como testar, riscos e evidência. Evite colar somente o nome da tarefa. O revisor precisa saber qual comportamento era esperado e qual decisão merece atenção.

Um modelo curto pode conter: contexto, mudanças, teste manual, testes automatizados e itens fora do escopo. Screenshots ajudam quando o resultado é visual, mas não substituem teste. Links de issue devem explicar a relação, não ser a única especificação.

Revisão é conversa sobre o diff

Comentário geral discute arquitetura; comentário em linha aponta uma região; sugestão oferece uma alteração pequena. “Request changes” bloqueia aprovação até resolver itens necessários. “Approve” declara que a pessoa revisora aceita o estado observado, respeitando regras do repositório.

Responder não significa aceitar tudo sem raciocínio. Explique a decisão, pergunte quando o pedido é ambíguo e crie um novo commit na mesma branch. O PR atualiza automaticamente porque acompanha a referência remota. Não abra outro PR para cada rodada.

Antes de marcar uma conversa como resolvida, confirme que o código e o teste respondem ao ponto. Um comentário “feito” sem commit correspondente empurra a descoberta para o fim. Quando você discorda, registre o trade-off de forma técnica; revisão saudável melhora a decisão, não mede obediência. Também revalide o diff completo depois de muitas rodadas, porque duas sugestões boas isoladamente podem interagir de forma ruim.

Merge commit preserva os commits e a bifurcação

O sandbox integrou a feature com --no-ff. O desenho ficou:

git --no-pager log --oneline --graph --decorate main-merge -5

Essa opção mostra a unidade da tarefa e conserva commits originais. O custo é um grafo mais ramificado. Faz sentido quando os commits intermediários têm valor e o time quer preservar a topologia.

Squash cria um commit novo com o resultado inteiro

O mesmo diff foi aplicado com squash e commitado uma vez:

git --no-pager log --oneline --graph --decorate main-squash -4

Os dois commits da feature não viraram ancestrais da branch resultante. O código está lá, mas o histórico registra uma decisão consolidada. É útil quando a branch tem ajustes de revisão sem valor isolado. Escreva bem a mensagem de squash; ela será o registro permanente.

Rebase merge reaplica commits sem commit de merge

Na opção de rebase da interface, o GitHub reaplica commits na base e atualiza a branch alvo sem um nó de merge. Em um teste local equivalente, dois hashes mudaram de 58c1ad9 e 1b1f35b para 452b88d e b287fa5:

git --no-pager log --oneline --graph -4

O histórico fica linear e mantém a separação dos commits, mas recria objetos. O guia de rebase detalha conflitos e regra de ouro.

Feche o ciclo nas duas pontas

Depois do merge no GitHub, atualize main local com fetch e pull conforme a política. Apague a branch somente após confirmar integração. No sandbox, a branch estava contida em main-merge:

git branch -d feat/busca
git push origin --delete feat/busca

Em fork, origin costuma ser seu fork e upstream o projeto original. Você envia para seu fork e abre PR contra upstream. Permissão de leitura não concede push no original; a plataforma usa o PR para revisão.

Sua missão é preparar uma branch pequena, escrever uma descrição verificável e comparar os três grafos locais. Depois abra um PR somente em repositório seu ou com autorização. Termine quando souber justificar merge, squash ou rebase pelo histórico desejado, conectando merge, remote e push e fluxo em time.