Até agora, você aprendeu a criar universos paralelos (branches) no seu computador e juntá-los usando o git merge. Mas no mundo real, trabalhando em uma empresa, as coisas funcionam um pouco diferente.

Imagine que você está escrevendo um livro com outros autores. Você não pode simplesmente colar o seu capítulo novo no livro original sem que ninguém leia antes, certo? O editor precisa revisar, corrigir possíveis erros de português e garantir que a história faz sentido.

No GitHub, a branch main (o código oficial que está no ar) é protegida por uma "alfândega". Você não faz o merge direto nela. Em vez disso, você envia o seu universo paralelo para a nuvem e cria um Pull Request (PR).

O que é um Pull Request? A tradução literal seria "Pedido para Puxar". É você dizendo para a sua equipe: "Galera, terminei minha nova funcionalidade no meu universo. Alguém pode revisar e puxar (pull) esse código para o universo principal?"

O Fluxo de Trabalho Profissional

Quando trabalhamos em equipe, o ciclo de vida ganha algumas etapas extras na nuvem:

1. Você cria a branch localmente e programa.

2. Você envia (push) essa branch para o GitHub.

3. Você abre o Pull Request no site do GitHub.

4. Seus colegas revisam o código (Code Review).

5. Se tudo estiver certo, o PR é aprovado e o código é fundido (merge) pelo próprio site.

Exercício Prático: O Seu Primeiro Pull Request

Objetivo: Criar uma nova funcionalidade, enviá-la para o GitHub e abrir um pedido formal para que ela entre no código principal do sistema Construcom.

Passo 1: Criando o código novo (no seu universo)

1. No seu terminal, garanta que está na branch principal atualizada:

   git checkout main
git pull

2. Crie um novo universo para a funcionalidade de relatórios:

   git branch feature-relatorio
git checkout feature-relatorio

3. Crie um arquivo chamado relatorios.php e adicione o seguinte código:

   <?php
   echo "<h1>Relatório de Entregas do Mês</h1>";
   echo "<p>Total de entregas concluídas: 145</p>";
   ?>

4. Salve essa foto (commit):

   git add relatorios.php

   git commit -m "Cria pagina inicial de relatorios de entrega"

Passo 2: Enviando o universo paralelo para a nuvem Até agora, o GitHub não sabe que a branch feature-relatorio existe. Precisamos empurrar esse universo inteiro para lá:

git push origin feature-relatorio

(O origin é o apelido padrão que o Git dá para o seu repositório no GitHub).

Passo 3: A Alfândega (Criando o PR no site)

1. Abra o site do GitHub e acesse o repositório do seu projeto.

2. Você verá um aviso amarelo ou verde em destaque dizendo que a branch feature-relatorio acabou de receber alterações, com um botão chamado "Compare & pull request". Clique nele!

3. Preenchendo o formulário:

   • Título: O GitHub vai puxar a mensagem do seu commit, mas você pode melhorar. (Ex: Criação do módulo de relatórios mensais).

   • Descrição: É aqui que você "vende" o seu código. Escreva o que você fez, para que serve e se tem algo que a equipe precise testar.

4. Clique no botão verde "Create pull request".

Parabéns! O seu pedido foi criado. Agora, em um cenário real, seus colegas entrariam nessa tela, clicariam na aba "Files changed" (Arquivos alterados) e veriam exatamente as linhas verdes (código novo) que você adicionou, podendo até deixar comentários específicos em linhas de código (o famoso Code Review).

Passo 4: A Aprovação e o Merge Como estamos simulando isso sozinhos, você mesmo será o revisor.

1. Na página do seu Pull Request, role até o final.

2. Clique no grande botão verde "Merge pull request" e depois em "Confirm merge".

3. O ícone do PR vai mudar para roxo (Merged). Isso significa que a alfândega liberou sua bagagem e o código da sua branch agora faz parte oficialmente da main na nuvem!

Passo 5: Atualizando o seu computador A nuvem está atualizada com os relatórios, mas o universo main no seu computador ainda está desatualizado. Vamos trazer essa novidade de volta para casa:

git checkout main
git pull

Agora sim, você completou o ciclo completo de um desenvolvedor profissional!

Dicas de Ouro para Pull Requests

• Pequenos e Focados: Ninguém gosta de revisar um Pull Request com 50 arquivos modificados de uma vez. Faça PRs pequenos (ex: apenas a tela de login, e não o sistema de login + banco de dados + relatórios juntos).

• Cuidado com a Descrição: Um PR sem descrição é como entregar um pacote misterioso sem remetente. Facilite a vida de quem vai revisar seu código.

• O Código não foi aceito? Tudo bem! É super comum os colegas pedirem alterações. Você não precisa fechar o PR. Basta voltar ao seu código, fazer a alteração, dar um novo git add e git commit, e depois um git push. O Pull Request na nuvem vai se atualizar automaticamente com a sua correção!