Git se torna muito mais poderoso quando várias pessoas trabalham no mesmo projeto. Nesta aula, o objetivo é entender o fluxo mais comum usado em equipes.
Issue
↓
Branch
↓
Commits
↓
Push
↓
Pull Request
↓
Code Review
↓
Ajustes
↓
Merge
↓
main
Esses termos são parecidos, mas representam coisas diferentes.
git clone cria uma cópia local de um repositório que já existe.
GitHub
│
└──── git clone ────► seu computador
Exemplo:
git clone https://github.com/usuario/projeto.gitUm fork cria uma cópia do repositório na sua própria conta do GitHub.
repositório original
│
└──── Fork ────► sua conta GitHub
│
└──── clone ────► computador
Forks são comuns quando você quer contribuir com um projeto no qual não possui permissão de escrita direta.
| Ação | Onde cria a cópia? | Uso comum |
|---|---|---|
clone |
no seu computador | trabalhar localmente |
fork |
na sua conta do GitHub | contribuir sem acesso direto ao original |
Ao clonar seu próprio fork, normalmente:
origin → seu fork
upstream → repositório original
Adicione o repositório original como upstream:
git remote add upstream https://github.com/autor-original/projeto.gitConfira:
git remote -vExemplo mental:
upstream
▲
│
repositório original ──┘
seu fork ─────────────► origin
▲
│
seu computador
Em muitas equipes, o trabalho começa com uma Issue.
Uma issue pode descrever:
- um bug;
- uma nova funcionalidade;
- uma melhoria de documentação;
- uma tarefa técnica.
Exemplo:
Issue #42
Título: Corrigir validação do formulário de login
Problema:
O formulário permite envio sem e-mail.
Critério de aceite:
- e-mail obrigatório;
- mensagem de erro visível;
- envio bloqueado quando inválido.
Isso reduz ambiguidade antes de começar o código.
Evite desenvolver diretamente na main.
git switch main
git pull
git switch -c fix/validacao-loginUm padrão simples de nomes:
feat/nova-funcionalidade
fix/correcao-de-bug
docs/documentacao
refactor/melhoria-interna
Evite um único commit gigantesco chamado:
arrumei tudo
Prefira algo como:
fix: valida campo de email
test: cobre envio sem email
docs: documenta comportamento do formulario
Um bom commit facilita:
- revisar;
- encontrar quando algo mudou;
- reverter uma alteração específica;
- entender o histórico meses depois.
Enquanto você trabalha, a main pode avançar.
main A────B────E
\
feature C────D
Sua branch possui trabalho novo (C e D), mas não possui E.
Atualize as referências remotas:
git fetch originDepois integre a main conforme o fluxo da equipe:
git merge origin/mainou, se a equipe usar rebase:
git rebase origin/mainNão escolha merge ou rebase no automático. Siga o padrão definido pelo projeto.
git push -u origin fix/validacao-loginAgora a branch existe também no GitHub.
branch local
│
└──── push ────► branch remota
Um Pull Request (PR) é um pedido para integrar alterações de uma branch em outra.
fix/validacao-login
│
└──── Pull Request ────► main
Um PR bem descrito deve responder:
- O que mudou?
- Por que mudou?
- Como verificar?
- Há algum risco ou detalhe importante?
Exemplo:
## O que mudou
- adiciona validação obrigatória de e-mail;
- exibe mensagem quando o campo está vazio.
## Como testar
1. abrir o formulário;
2. deixar e-mail vazio;
3. clicar em enviar;
4. confirmar que o envio é bloqueado.No review, outra pessoa analisa o diff antes do merge.
O objetivo não é procurar culpados. O review ajuda a verificar:
- corretude;
- legibilidade;
- efeitos colaterais;
- testes;
- segurança;
- aderência ao padrão do projeto.
Em vez de:
Isso está errado.
Prefira algo específico:
Podemos extrair essa validação para uma função? Assim evitamos duplicação nos dois formulários.
Normalmente, não.
Continue na mesma branch:
# faça a correção
git add .
git commit -m "fix: ajusta validacao conforme review"
git pushO Pull Request é atualizado automaticamente.
mesma branch
↓ novo commit
↓ push
mesmo Pull Request atualizado
Depois da aprovação, a branch pode ser integrada à main.
Os três métodos mais conhecidos são:
| Método | Resultado geral |
|---|---|
| Merge commit | preserva as linhas de histórico e cria um commit de merge |
| Squash and merge | transforma os commits do PR em um único commit na base |
| Rebase and merge | reaplica os commits sobre a base sem criar merge commit |
Nenhum é universalmente melhor. Projetos diferentes adotam políticas diferentes.
Atualize sua main local:
git switch main
git pullExclua a branch local se ela já terminou:
git branch -d fix/validacao-loginEm projetos colaborativos, a main pode ser protegida para impedir alterações diretas.
Um fluxo possível:
push direto na main ❌
branch → Pull Request → aprovação → checks → merge ✅
Isso ajuda a evitar que código não revisado entre na linha principal.
1. Fork do projeto
↓
2. Clone do seu fork
↓
3. Adiciona upstream
↓
4. Cria branch
↓
5. Commits
↓
6. Push para origin (seu fork)
↓
7. PR para o repositório original
↓
8. Review
↓
9. Merge
Antes de contribuir, procure arquivos como:
CONTRIBUTING.md
CODE_OF_CONDUCT.md
README.md
Eles podem conter regras específicas do projeto.
Este repositório possui um CONTRIBUTING.md com um fluxo de contribuição didático.
Você pode usar esse documento para entender como um projeto real comunica:
- como criar branches;
- padrão de commits;
- como montar um PR;
- o que revisar antes de enviar.
Para praticar sem gerar PRs desnecessários no projeto original, você pode fazer um fork e abrir o Pull Request entre uma branch e a
maindo seu próprio fork.
- Sei explicar clone x fork.
- Entendo
originxupstream. - Sei por que equipes usam Issues.
- Sei criar uma branch para uma tarefa.
- Sei abrir e atualizar um Pull Request.
- Entendo o objetivo de code review.
- Sei o que acontece depois do merge.
- Entendo por que uma
mainpode ser protegida.