O que é branch no Git e como organizar o trabalho em ramificações

Uma branch no Git é só um ponteiro: um arquivo minúsculo que guarda o identificador de um commit. Criar uma não copia pasta nenhuma, não duplica o projeto e leva menos de um segundo, mesmo num repositório com milhares de arquivos. É por isso que times criam e apagam branches o tempo todo, uma para cada tarefa, sem pensar duas vezes.

Essa resposta curta resolve a dúvida mais comum de quem vem de outras ferramentas, onde “ramificar” significava copiar diretórios inteiros. No Git, a ramificação é barata porque o histórico já está todo guardado, e a branch apenas aponta para um lugar dentro dele. Entender esse mecanismo explica por que alguns comandos se comportam como se comportam e ajuda a escolher um modelo de organização que faça sentido para o seu time.

Por dentro de uma branch: commits encadeados e um ponteiro móvel

Cada commit no Git guarda um retrato do projeto e uma referência ao commit anterior (o “pai”). Encadeados, eles formam o histórico. Uma branch é um nome, como main ou tela-login, que aponta para o commit mais recente daquela linha de trabalho.

O livro Pro Git, no capítulo sobre branches, mostra isso com diagramas: quando você faz um commit novo, o ponteiro da branch atual simplesmente anda para frente e passa a apontar para ele. Nada mais muda.

Existe ainda um ponteiro especial, o HEAD, que indica em qual branch você está agora. Quando você troca de branch, o Git move o HEAD e reescreve os arquivos da pasta de trabalho para que fiquem iguais ao commit apontado.

Criar, trocar e listar branches na prática

Desde a versão 2.23, o Git tem o comando git switch, mais claro para quem está começando do que o antigo git checkout, que fazia coisas demais. Os comandos do dia a dia são poucos:

git branch                  # lista as branches locais (a atual tem *)
git switch -c tela-login    # cria a branch e já entra nela
git switch main             # volta para a main
git branch -d tela-login    # apaga a branch (se já foi mesclada)
git push -u origin tela-login  # envia a branch para o remoto

A referência oficial do git switch lista as opções menos usadas, como criar a branch a partir de um commit específico.

O que acontece com arquivos não commitados quando você troca de branch

Se as alterações não conflitam com a branch de destino, elas vão junto com você. Se conflitam, o Git recusa a troca e avisa. Isso surpreende muita gente: alterações não commitadas não pertencem a nenhuma branch, pertencem à pasta de trabalho. Antes de trocar, faça commit ou guarde com git stash.

Branch local e branch remota não são a mesma coisa

A sua main e a origin/main são ponteiros diferentes. A segunda é a lembrança que o seu Git tem de onde a main estava no servidor da última vez que você conversou com ele. git fetch atualiza essa lembrança, git pull atualiza e mescla na sua branch local.

Duas linhas que se separam: o que a ramificação permite

Imagine uma loja virtual com a main em produção. Você cria cupom-desconto para uma funcionalidade nova que vai levar uma semana. Na quarta, aparece um bug no cálculo do frete. Sem branches, você teria código pela metade misturado com a correção urgente. Com elas, o fluxo fica assim:

1. Commit do que já fez em cupom-desconto, mesmo incompleto.
2. git switch main e git switch -c corrige-frete.
3. Corrige, testa, abre o pull request, mescla na main e publica.
4. git switch cupom-desconto e continua de onde parou.
5. Antes de terminar, traz a correção do frete com git merge main.

Repare no passo 5. Ele é o que muita gente esquece: a sua branch nasceu antes da correção, então não sabe que ela existe. Se você não trouxer a main atualizada, o pull request do cupom pode até reintroduzir o cálculo antigo do frete, dependendo de como os arquivos se cruzam.

Esse isolamento é a razão de existir das branches: trabalhos em ritmos diferentes que não atrapalham um ao outro até a hora de juntar.

Os modelos de organização de branches mais usados pelos times

O mecanismo é o mesmo para todos. O que muda é a combinação que cada time adota: quantas branches permanentes existem, quanto tempo uma branch de tarefa vive e por onde o código chega à produção.

O GitHub Flow, descrito na documentação do GitHub, é o mais simples e o que a maioria dos devs juniores encontra no primeiro emprego: cria a branch, faz commits, abre pull request, revisa, mescla e apaga.

O Git Flow, popularizado por Vincent Driessen em 2010, ainda aparece em empresas que lançam versões de aplicativo para lojas ou software instalado em clientes. O próprio autor acrescentou uma nota ao texto original dizendo que, para aplicações web entregues continuamente, um fluxo mais simples costuma servir melhor.

Nomes de branch que o time inteiro entende

O Git aceita quase qualquer nome, mas convenção ajuda a achar as coisas. Os padrões mais comuns usam um prefixo de tipo e uma descrição curta:

• feature/cupom-desconto ou feat/cupom-desconto para funcionalidade nova;
• fix/calculo-frete para correção;
• chore/atualiza-dependencias para manutenção;
• número do ticket no nome (fix/482-calculo-frete) quando o time usa Jira ou issues.

Alguns times também protegem a branch principal com regras na plataforma: ninguém envia commits direto para ela, todo código entra por pull request, e o merge só é liberado com pelo menos uma aprovação e os testes passando. Se você receber um erro de “protected branch” ao tentar um git push para a main, é isso que está acontecendo, e a saída é criar a sua branch e abrir o pedido.

Evite espaços, acentos e nomes genéricos como teste ou minha-branch. Daqui a um mês ninguém, nem você, vai lembrar o que tinha nela.

Ponteiros baratos, hábitos melhores para o dev júnior

Saber que branch é só um ponteiro tira o peso de criar uma. Crie uma para cada tarefa, por menor que seja, e apague depois do merge. Nunca trabalhe direto na main de um projeto compartilhado: muitos repositórios bloqueiam isso por regra de proteção, e os que não bloqueiam vão te ensinar o motivo do pior jeito.

A recomendação direta: quanto menos tempo a branch vive, menos conflito ela gera. Uma tarefa que leva duas semanas pode ser quebrada em entregas menores, cada uma com sua branch e seu pull request. Se quiser ver como isso se conecta ao resto do vocabulário (commit, merge, HEAD, rebase), o glossário de programação do portal tem uma página para cada termo. E para entender como as plataformas já automatizam parte desse fluxo, vale ler sobre o GitHub Agentic Workflows.