Branches: o conceito central do Git

1. O que é uma branch? A metáfora da linha do tempo paralela

1.1. Definição fundamental: um ponteiro móvel para um commit

No Git, uma branch é, essencialmente, um ponteiro leve e móvel para um commit específico. Diferente de outros sistemas de controle de versão que copiam arquivos inteiros para criar ramificações, o Git trata branches como simples referências de 41 bytes (40 caracteres do hash SHA-1 mais uma quebra de linha). Quando você faz um novo commit, o ponteiro da branch atual avança automaticamente para apontar para esse novo commit.

1.2. Analogia prática: branches como "realidades alternativas" do seu projeto

Pense em branches como universos paralelos do seu código. A branch main representa a linha do tempo principal, estável e testada. Ao criar uma nova branch, você está essencialmente dizendo: "Quero explorar uma realidade alternativa onde implemento uma nova funcionalidade, corrijo um bug ou experimento uma abordagem diferente". Cada branch tem seu próprio histórico de commits, e você pode alternar entre elas sem que as mudanças de uma interfiram na outra.

1.3. A branch padrão main (ou master) e sua importância

Historicamente, o Git criava a branch padrão com o nome master. Desde 2020, a comunidade adotou main como nome padrão, promovendo uma terminologia mais inclusiva. A branch main (ou master) é a linha de desenvolvimento principal do projeto — o ponto de partida para praticamente todas as outras branches e o local onde o código estável reside.

2. A mecânica interna: como o Git gerencia branches

2.1. O arquivo .git/HEAD e o ponteiro da branch atual

O Git usa o arquivo .git/HEAD para saber em qual branch você está trabalhando. Se você estiver na branch main, o conteúdo desse arquivo será:

ref: refs/heads/main

Isso indica que o HEAD é um "ponteiro simbólico" para a branch main. Quando você faz um commit, o Git lê o HEAD, descobre para qual branch ele aponta e move o ponteiro dessa branch para o novo commit.

2.2. Referências em .git/refs/heads/: o diretório onde as branches vivem

Cada branch local é representada por um arquivo dentro do diretório .git/refs/heads/. Por exemplo, se você criar uma branch chamada feature/login, o Git criará o arquivo .git/refs/heads/feature/login contendo o hash do commit para o qual essa branch aponta:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

2.3. O que acontece exatamente quando você faz um commit em uma branch

Quando você executa git commit, o Git:

  1. Cria um novo objeto commit com base no conteúdo do índice (staging area)
  2. Define o pai do novo commit como o commit atual apontado pela branch
  3. Atualiza o arquivo da branch em .git/refs/heads/ para apontar para o novo commit

Esse processo é extremamente rápido porque o Git não copia arquivos — apenas atualiza um ponteiro.

3. Criando e nomeando branches: boas práticas

3.1. Comando git branch <nome>: criando uma nova ramificação

Para criar uma nova branch a partir do commit atual:

git branch feature/nova-funcionalidade

Isso cria um novo arquivo em .git/refs/heads/feature/nova-funcionalidade com o mesmo hash do commit atual, mas você ainda permanece na branch original.

3.2. Convenções de nomenclatura: feature/, bugfix/, hotfix/

Boas práticas de nomenclatura incluem:

  • feature/: para novas funcionalidades (ex: feature/autenticacao-2fa)
  • bugfix/: para correções de bugs não críticos (ex: bugfix/corrigir-botao-login)
  • hotfix/: para correções urgentes em produção (ex: hotfix/vulnerabilidade-xss)
  • release/: para preparar versões de lançamento (ex: release/v2.1.0)

3.3. A diferença entre criar uma branch e mudar para ela

O comando git branch apenas cria a branch. Para criar e já mudar para ela, use:

git checkout -b feature/nova-funcionalidade

Ou, de forma mais moderna e segura:

git switch -c feature/nova-funcionalidade

O git switch -c é preferível por ser mais explícito e evitar ambiguidades do checkout.

4. Navegando entre branches: checkout e switch

4.1. git checkout <branch>: a forma clássica

O comando git checkout altera o HEAD para apontar para a branch especificada e atualiza o diretório de trabalho para refletir o estado daquela branch:

git checkout main

4.2. git switch <branch>: o comando moderno e mais seguro

Introduzido no Git 2.23, git switch faz exatamente o que o nome sugere — alterna entre branches:

git switch feature/nova-funcionalidade

Diferente do checkout, o switch não permite operações confusas como criar branches ou restaurar arquivos, tornando-o mais seguro e intuitivo.

4.3. O problema das mudanças não commitadas ao trocar de branch

Se você tiver mudanças não commitadas no diretório de trabalho, o Git pode se recusar a trocar de branch para evitar perda de dados. Soluções:

# Salvar temporariamente as mudanças
git stash

# Trocar de branch
git switch main

# Recuperar as mudanças depois
git stash pop

Ou, para mudanças simples, você pode fazer um commit temporário:

git add .
git commit -m "WIP: mudanças temporárias"

5. O ciclo de vida de uma branch: fusão e exclusão

5.1. Integrando trabalho: o papel do merge (visão geral)

Quando o trabalho em uma branch é concluído, você geralmente quer integrá-lo de volta à branch principal. O merge combina o histórico de duas branches:

git switch main
git merge feature/nova-funcionalidade

5.2. Deletando branches: git branch -d (seguro) vs git branch -D (forçado)

Após o merge, você pode deletar a branch de feature:

# Seguro: só deleta se a branch foi totalmente mesclada
git branch -d feature/nova-funcionalidade

# Forçado: deleta mesmo sem merge (cuidado!)
git branch -D feature/experimento-abortado

5.3. O que acontece com os commits após deletar uma branch?

Deletar uma branch não deleta os commits imediatamente. Os commits permanecem no repositório até serem limpos pelo garbage collector (geralmente após 30 dias). Você pode recuperá-los usando:

git reflog

6. Trabalhando com branches remotas

6.1. Branches locais vs. branches de rastreamento remoto

Branches locais existem apenas na sua máquina. Branches de rastreamento remoto (como origin/main) são referências locais que espelham o estado das branches no repositório remoto:

# Listar branches locais
git branch

# Listar branches remotas
git branch -r

# Listar todas as branches
git branch -a

6.2. Publicando uma branch local: git push -u origin <branch>

Para compartilhar sua branch local com outros desenvolvedores:

git push -u origin feature/nova-funcionalidade

A flag -u (ou --set-upstream) configura o rastreamento, permitindo que você use apenas git push e git pull no futuro.

6.3. Atualizando referências locais: git fetch e a sincronização com o remoto

git fetch baixa as referências do remoto sem mesclar automaticamente:

git fetch origin

Isso atualiza suas branches de rastreamento remoto (como origin/main), mas não altera suas branches locais.

7. Cenários comuns e resolução de problemas

7.1. Branch "perdida": como recuperar commits de uma branch deletada

Se você acidentalmente deletou uma branch que ainda não foi mesclada:

# Encontrar o hash do último commit da branch deletada
git reflog

# Recriar a branch a partir desse commit
git branch branch-recuperada <hash-do-commit>

7.2. Conflitos ao trocar de branch: o que fazer quando o Git se recusa

Se o Git se recusar a trocar de branch por causa de mudanças não commitadas:

# Verificar o status
git status

# Opção 1: Stash
git stash
git switch outra-branch
git stash pop

# Opção 2: Commit temporário
git add .
git commit -m "salvando progresso"
git switch outra-branch

7.3. Estratégia básica de branches: Git Flow vs. GitHub Flow

Git Flow: Estratégia mais complexa com branches develop, feature/, release/ e hotfix/. Ideal para projetos com ciclos de release definidos.

GitHub Flow: Abordagem mais simples com apenas main e branches de feature. Cada feature é desenvolvida em uma branch separada e integrada via Pull Request. Ideal para deploy contínuo.

Ambas as estratégias utilizam o mesmo conceito fundamental de branches, mas diferem na estrutura e no fluxo de trabalho.

Referências