Git na prática: branches, pull requests e como resolver conflitos

Atualizado em 3 de novembro de 2026 · Leitura de 6 min

Edson Feitosa de Oliveira Junior Fundador e Engenheiro Líder · PruPru Digital Services

Trabalhar com Git branches e pull requests é o passo seguinte ao básico do Git (commit, push, pull): cada mudança fica em uma branch separada, revisada por meio de um pull request antes de entrar no código principal. Esse fluxo evita que código quebrado chegue à produção, deixa um histórico claro de cada decisão e é exatamente o que empresas esperam de um desenvolvedor júnior. Se você ainda não conhece os comandos básicos, comece por Git e GitHub para iniciantes.

O que é uma branch no Git

Uma branch é uma linha independente de desenvolvimento. A branch principal (normalmente main) guarda o código estável. Para cada nova funcionalidade ou correção, você cria uma branch, trabalha nela e, quando terminar, propõe juntar as mudanças à main.

git switch main
git pull                          # atualiza a main
git switch -c feature/login       # cria a branch e entra nela

Em versões antigas do Git, o equivalente é git checkout -b feature/login.

Nomes de branch

Use nomes que digam o propósito: feature/cadastro-cliente, fix/erro-calculo-frete, docs/readme-instalacao. Muitas equipes incluem o número da tarefa: fix/231-calculo-frete.

Commits pequenos e com boas mensagens

Faça commits a cada passo lógico, não um commit gigante no fim do dia:

git add src/main/java/.../ClienteController.java
git commit -m "Adiciona validação de e-mail no cadastro de cliente"

Boas mensagens dizem o que mudou e, se necessário, por quê. "Ajustes" e "correções" não ajudam ninguém daqui a seis meses.

Enviando e abrindo o pull request

git push -u origin feature/login

No GitHub, aparece a opção de abrir um pull request (PR). Um bom PR tem:

1. Título claro: "Adiciona login com e-mail e senha".
2. Descrição: o que foi feito, por quê, e como testar.
3. Tamanho razoável: PRs pequenos são revisados mais rápido e com mais cuidado. Se ficou enorme, divida.
4. Testes: inclua ou atualize os testes. Veja testes automatizados com JUnit.
5. Prints, se houver mudança visual.

Modelo de descrição:

## O que muda
Adiciona endpoint POST /auth/login com validação de credenciais.

## Por quê
Necessário para o painel do cliente (tarefa #231).

## Como testar
1. Rode a aplicação com o perfil dev.
2. Envie POST /auth/login com o usuário de teste.
3. Verifique o token retornado.

Rascunhos (draft pull requests) são úteis para mostrar trabalho em andamento e pedir opinião cedo.

Revisão de código

A revisão (code review) é onde a equipe aprende junto. Ao receber comentários:

• não leve para o lado pessoal: a revisão é sobre o código;
• responda a cada comentário, mesmo que seja para explicar uma decisão;
• faça os ajustes em novos commits na mesma branch; o PR é atualizado automaticamente.

Ao revisar o código de outra pessoa, seja específico e gentil: "Este método pode retornar null quando o cliente não existe; que tal usar Optional?" é melhor que "isso está errado".

Mantendo a branch atualizada

Enquanto você trabalha, outras pessoas atualizam a main. Para trazer essas mudanças:

git switch main
git pull
git switch feature/login
git merge main

Algumas equipes preferem git rebase main, que deixa o histórico linear. Regra importante: não faça rebase de branches que outras pessoas também usam, porque o rebase reescreve o histórico.

Resolvendo conflitos

Um conflito acontece quando duas pessoas alteram as mesmas linhas. O Git marca o trecho:

<<<<<<< HEAD
private static final int LIMITE = 10;
=======
private static final int LIMITE = 20;
>>>>>>> main

Para resolver:

1. Abra o arquivo e decida o conteúdo correto. Às vezes é uma das versões, às vezes a combinação das duas.
2. Remova os marcadores <<<<<<<, ======= e >>>>>>>.
3. Compile e rode os testes.
4. Marque como resolvido e finalize:

git add arquivo-resolvido.java
git commit

IDEs como IntelliJ e VS Code têm ferramentas visuais que facilitam muito essa etapa. Se tiver dúvida sobre a intenção da outra mudança, pergunte a quem a fez.

Formas de fazer o merge

Siga o padrão da equipe. Depois do merge, apague a branch.

Desfazendo erros comuns

• Mudanças não commitadas que você quer descartar: git restore arquivo.
• Arquivo adicionado por engano: git restore --staged arquivo.
• Mensagem errada no último commit (ainda não enviado): git commit --amend.
• Desfazer um commit já enviado: git revert <hash>, que cria um novo commit invertendo as mudanças, sem reescrever o histórico.
• Trabalho em andamento que precisa ficar de lado: git stash e, depois, git stash pop.
• "Perdi um commit": git reflog mostra tudo o que aconteceu recentemente e permite recuperar quase qualquer coisa.

Evite git push --force em branches compartilhadas. Se precisar, prefira git push --force-with-lease, que não sobrescreve trabalho que você ainda não viu.

Proteção da branch principal

No GitHub, configure regras para a main: exigir pull request, exigir aprovação e exigir que os testes passem. Isso impede que alguém envie código direto para produção por engano. Se o site é publicado automaticamente a partir da main, essas regras são ainda mais importantes; veja deploy de site estático grátis.

Por que isso importa para a carreira

Um perfil no GitHub com projetos organizados em branches, PRs bem descritos e testes mostra que você sabe trabalhar em equipe. Veja portfólio de desenvolvedor júnior e entrevista técnica para júnior.

Perguntas frequentes