O que um pull request realmente é

Um conceito que o GitHub inventou, não o Git

Todo merge do curso anterior aconteceu inteiramente na linha de comando: você decidiu que o branch estava pronto, rodou git merge, ninguém mais participou. Isso funciona para um projeto sozinho. Isso quebra quando uma segunda pessoa precisa ver o código antes de ele chegar ao main. "Alguém revisa isso antes de mesclar" não é um recurso do Git. É do GitHub.

A camada que o GitHub adiciona por cima do Git

Um pull request (PR) é um pedido, hospedado no GitHub, para mesclar um branch em outro. Ele envolve numa camada social e técnica o git merge que você já sabe rodar na mão:

              git push
Branch local  ────────▶  Branch remoto           Pull Request
(seu notebook)            (no GitHub)       ────▶  - mostra o diff
                                                     - coleta comentários
                                                     - roda checagens de CI
                                                     - controla o botão de merge

O GitLab chama a mesma coisa de "merge request"; o Bitbucket também diz "pull request". Nada disso é Git; é uma aplicação web construída em cima de branches e diffs do Git.

Por que essa camada existe

• Revisão de código: um segundo par de olhos pega bugs, sugere abordagens melhores, e espalha conhecimento sobre a base de código pelo time.
• Um rastro documentado: a discussão por trás de uma mudança fica presa ao diff dela. Um ano depois, ela responde "por que isso foi escrito assim?"
• Portões automatizados: o CI roda a suíte de testes e mantém o botão de merge desabilitado até ela passar. Os erros param antes de chegar ao main.
• Um ponto de checagem natural: a plataforma garante a regra do curso de Branching de que o main fica pronto para deploy, sem depender de boa vontade.

O formato do ciclo inteiro

1. Cria um branch a partir do main, faz o trabalho    (curso de Branching)
2. Commita de forma limpa, dá push no branch          (cursos de Workflow + Remotos)
3. Abre um pull request                               ← este curso começa aqui
4. Revisores comentam, você responde
5. As checagens passam, o revisor aprova
6. Mescla — pelo botão do GitHub, não pelo seu terminal
7. Apaga o branch, dá pull no main localmente

Os passos 1 e 2 são tudo que os últimos quatro cursos construíram. Este curso pega de onde o git push parou.

Como este curso está organizado

• Aula 2: abrindo um pull request: branch base, descrição, rascunhos
• Aula 3: lendo o diff e deixando comentários inline
• Aula 4: respondendo a feedback: dando push em mais commits, resolvendo conversas
• Aula 5: aprovações, checagens obrigatórias e proteção de branch
• Aula 6: as três estratégias de merge que o GitHub oferece, e como elas se ligam ao que você já sabe
• Aula 7: abrindo, revisando e mesclando um pull request de verdade, de ponta a ponta

Pontos-chave

• Um pull request é um recurso do GitHub, não do Git: ele envolve um git merge em revisão, discussão e checagens automatizadas.
• O GitLab chama a mesma ideia de "merge request": mesmo conceito, plataforma diferente.
• O objetivo é revisão de código, um registro permanente do porquê de uma mudança, e portões automatizados antes do código chegar ao main.
• Este curso começa onde o git push do curso anterior parou: um branch que existe no remoto, pronto para ser revisado.