Git Branching: O Que Todo Dev Precisa Saber

Fonte: Unsplash

A maior parte dos erros graves com Git não acontece por não saber comitar. Acontece por tratar branch como cópia de segurança — aquela pastinha que você cria "para experimentar", acumula seis meses de alteração e só descobre o problema na hora de voltar para o main.

Branching é o mecanismo mais barato que o Git tem para você arriscar. Quem entende o modelo mental por trás dele para de decorar comandos e passa a decidir. Este texto cobre exatamente isso: como pensar, quais comandos importam e onde a maioria se machuca.

Branch não é cópia do projeto

Quando você cria uma branch, o Git não duplica os arquivos. Ele cria outro ponteiro para o mesmo histórico e passa a mover esse ponteiro conforme você comita. É por isso que criar e apagar branches custa quase nada — e também é por isso que apagar uma branch não apaga o trabalho feito nela, enquanto ele estiver no histórico.

git switch -c feature/login-social   # cria e entra
git switch main                      # volta
git branch -d feature/login-social   # apaga (seguro)
git branch -D feature/login-social   # apaga à força

Repare no -d versus -D: o primeiro se recusa a apagar branch que ainda tem commit não mesclado. É a rede de segurança que salva muito trabalho às sextas-feiras.

Os três padrões de fluxo e quando usar cada um

Trunk-based: todo mundo comita direto no main (ou em branches de vida curta, de horas). Exige integração contínua verde e disciplina de feature flag. Times maduros ganham velocidade; times iniciantes geram um main instável.

Git Flow clássico: main, develop, feature/*, release/* e hotfix/*. Continua fazendo sentido em produto com versões publicadas e janelas de release, mas é pesado para quem publica toda hora.

GitHub Flow: main sempre deployável + branch por tarefa + pull request obrigatório. É o meio-termo que mais funciona em equipe pequena e média: regra única, poucos nomes, revisão obrigatória.

Critério prático: se vocês publicam mais de uma vez por semana, comece pelo GitHub Flow. Só introduza develop e release/* quando existir de fato um ciclo de versão que não pode mudar.

O que acontece quando você mescla

git merge junta histórico. Com --no-ff, você força a criação de um commit de mesclagem que preserva visualmente a ponta da branch — muito útil para ler o histórico depois:

git switch main
git merge --no-ff feature/pagamento

git rebase reescreve: ele pega os seus commits e cola por cima do destino, gerando novos hashes. O histórico fica linear e bonito — e essa é a armadilha. Commit com hash novo é commit "outro" para todo mundo que já tinha baixado o anterior.

Regra que evita dor de cabeça: rebase só no que é seu. Reescreva a sua branch antes de abrir o pull request, à vontade. Depois que ela foi compartilhada, rebase de força é como apagar a memória dos outros.

Os comandos de emergência que você precisa decorar

Toda a árvore do Git é alcançável por refs. Se você perdeu um commit, apagou branch errado ou fez merge no lugar errado, o resgate é o mesmo caminho:

# o que aconteceu nos últimos passos?
git reflog

# volta para o estado anterior (ex.: antes do reset errado)
git reset --hard HEAD@{2}

# desfazer uma mesclagem já publicada, sem reescrever histórico
git revert -m 1 <hash-do-merge>

# traz um commit esquecido para a branch atual
git cherry-pick <hash>

# vê o que mudou entre duas branches, arquivo a arquivo
git diff main...feature/login

git revert é a versão segura do desfazer em time: ele cria um commit que anula outro, então nada que já foi publicado deixa de existir. Guarde essa distinção — reset reescreve o que é só seu, revert anula o que todo mundo já viu.

Conflito de merge sem pânico

Conflito não é erro de Git, é o Git te avisando que duas pessoas mexeram no mesmo trecho e ele não quer escolher por você. O fluxo é simples:

Abra o arquivo. Vou os marcadores <<<<<<<, ======= e >>>>>>>.
Decida o conteúdo final — pode ser os dois lados combinados, não precisa ser um ou outro.
Remova os marcadores, salve, git add o arquivo.
Quando todos os arquivos estiverem resolvidos: git merge --continue (ou git rebase --continue).

Três coisas reduzem conflito antes dele aparecer: branch de vida curta, git pull --rebase ao iniciar o turno e avisar no time quando for mexer em arquivo compartilhado. E se a bagunça ficou grande, git merge --abort / git rebase --abort devolvem tudo como estava — sem constrangimento.

Boas práticas que valem mais que atalhos

Uma branch, uma intenção: "corrigir-validacao-cpf", não "ajustes-gerais-joao". Nome ruim vira arquivo perdido no futuro.
Commit com verbo no imperativo: adiciona validação de e-mail. Quem lê o histórico entende sem abrir o diff.
Nunca comite segredo: token em arquivo é problema na hora do push. Rode git log -p e confira antes.
Atualize o branch antes de abrir PR: git fetch + git rebase origin/main economiza ciclos de revisão.
Confira o que vai entrar: git status e git diff --staged antes de cada git commit.

Git é uma ferramenta que recompensa quem entende o modelo e pune quem decora. Aprenda a ler o histórico (git log --oneline --graph --decorate), pratique revert e reflog em um repositório de testes e, quando o medo passar, você vai perceber que branching deixou de ser risco e virou a coisa mais rotineira do seu dia.

E aí, fez sentido?

Conte nos comentários sua experiência com Git branching — qual foi o maior apagão que você já se recuperou (ou quase) com reflog? — e se o artigo te ajudou, compartilhe com alguém que está com medo de criar a primeira branch. 👇