Git como ferramenta de pensamento

Existe uma divisão silenciosa entre quem usa Git como sistema de backup — "salvar o que escrevi, baixar o que outros escreveram, resolver conflitos quando aparecem" — e quem usa Git como ferramenta de pensamento — "estruturar como uma mudança aconteceu, deixar pegadas inteligíveis para quem ler depois, encontrar a origem de bugs em segundos com bisect, reorganizar a história antes de publicá-la". A diferença não é técnica; é mental. As mesmas vinte ferramentas estão disponíveis para os dois grupos, mas só o segundo as usa para pensar.

Este conceito existe para garantir que você esteja no segundo grupo. A hipótese de fundo é: histórico bem-construído é forma de design. Um log de commits com mensagens descritivas, agrupadas por intenção, em ordem que conta uma história, é um documento técnico tão importante quanto o código em si — ele explica por que o código está como está, em incrementos pequenos o suficiente para serem entendidos isoladamente. Quem investe nisso tem uma vantagem cumulativa enorme: code reviews mais rápidos, debugging mais barato, onboarding mais suave, refactorings mais seguros.

O modelo mental do Git

A primeira coisa a destravar é o modelo mental. Git não é um sistema de "versões de arquivos" como CVS ou SVN antigos. Git é um sistema de snapshots imutáveis conectados por relações de "pai":

• Cada commit é um snapshot do projeto inteiro num dado momento, identificado por um hash SHA-1/SHA-256.
• Cada commit tem zero, um, ou mais commits-pai (pais múltiplos = merge).
• Branches são apenas ponteiros móveis para um commit. main é literalmente um arquivo com um SHA dentro.
• HEAD é um ponteiro para o branch atual (ou commit direto, em "detached HEAD").
• Quando você "muda branch", o Git move o ponteiro HEAD; o conteúdo do diretório de trabalho é restaurado a partir do snapshot apontado.

Essa é toda a estrutura. Tudo o que Git faz — branch, merge, rebase, cherry-pick, bisect — é manipulação dessa árvore de snapshots. Quando você internaliza esse modelo, comandos param de parecer mágicos: você sempre pode visualizar "antes e depois" da operação como duas configurações da mesma árvore.

Commits atômicos — a unidade fundamental

Um commit "atômico" é um commit que faz uma coisa, completa, compreensível em isolamento. Não duas mudanças misturadas; não meia feature; não "WIP" pendurado. A heurística é: se você precisar reverter este commit, deveria ser uma operação semanticamente coerente.

O critério prático de Tim Pope, no clássico ensaio "A Note About Git Commit Messages": "if applied, this commit will [imperative description]". Se você consegue completar essa frase com uma única descrição clara, o commit é atômico. Se a descrição precisa de "e" para conectar duas coisas ("adiciona endpoint X e refatora o parser Y"), são dois commits.

Vantagens de commits atômicos:

• Review focada: revisor pode entender uma mudança por vez.
• Bisect funciona: git bisect consegue achar a causa de bugs por bisseção binária — mas só se cada commit for testável em isolamento.
• Revert preciso: você pode desfazer uma feature específica sem desfazer outras coisas que vieram juntas.
• Cherry-pick limpo: levar uma correção para outra branch é uma única operação.
• História como documentação: git log --oneline vira um relatório legível do que aconteceu, sem ruído.

Mensagens de commit — anatomia

Boa mensagem de commit tem estrutura. A convenção mais usada (e a que ferramentas como GitHub Linear renderizam melhor) tem três partes:

1. Linha de assunto (até 50 chars), no imperativo, sem ponto final. "Add retry logic to PaymentClient", não "Added retry logic" nem "Adding retry logic".
2. Linha em branco.
3. Corpo (opcional, mas recomendado para qualquer mudança não-trivial). Explica por quê, não o quê — o diff já mostra o quê. Linhas até 72 chars.

Add retry logic to PaymentClient

The payment gateway has been returning intermittent 503s
during peak hours, which today causes user-visible failures.
Add exponential backoff with jitter, max 3 retries.

Tested via integration test that simulates 503 from a
mock gateway. Production rollout via feature flag.

Refs: PAY-1234

O hábito de escrever mensagens assim é uma disciplina pequena que paga retornos enormes. Em três meses, alguém vai estar lendo o seu commit tentando entender por que aquilo foi feito. A mensagem é o presente que você dá para o futuro.

Rebase interativo — escultura de história

Rebase é a ferramenta de Git que mais separa quem flutua de quem comanda. Ela permite reescrever história local antes de publicá-la: reordenar commits, juntar (squash) commits relacionados, dividir um commit grande em vários menores, editar mensagens, eliminar commits indesejados.

# Rebase interativo dos últimos N commits
git rebase -i HEAD~N

# Abre editor com algo tipo:
pick a1b2c3d Add user model
pick d4e5f6g WIP fixing tests
pick h7i8j9k Add user endpoint
pick l0m1n2o WIP more fixes

# Você reorganiza:
pick a1b2c3d Add user model
fixup d4e5f6g WIP fixing tests
pick h7i8j9k Add user endpoint
fixup l0m1n2o WIP more fixes

# Resultado: 2 commits limpos em vez de 4 bagunçados.

Comandos interativos:

• pick: manter como está.
• reword: manter o conteúdo, mudar a mensagem.
• edit: pausar para edição manual do commit.
• squash: juntar com o anterior, combinando mensagens.
• fixup: como squash, mas descarta a mensagem deste.
• drop ou apagar a linha: descartar o commit.

Merge vs rebase — o debate eterno

Quando integrar mudanças entre branches, há duas estratégias:

• Merge: cria um commit de merge com dois pais. Preserva a história de que aquela branch existiu separadamente. História não-linear.
• Rebase: aplica seus commits em cima da branch destino, como se você tivesse escrito eles depois das mudanças deles. História linear.

Vantagens de merge: preservação fiel do que aconteceu — você consegue reconstruir "essa feature foi feita em paralelo a essa outra durante esse período". Vantagens de rebase: log linear, mais fácil de ler. Cada equipe escolhe o estilo.

Padrão prático que funciona bem na maioria dos times modernos:

1. Branches de feature: rebase em main antes de abrir PR. Mantém história linear, evita merges intermediários no log.
2. Merge do PR para main: squash-and-merge (junta tudo num único commit atômico) ou merge commit explícito. Squash funciona bem se cada PR representa uma mudança coerente.

git bisect — a ferramenta que ninguém conhece

Bisect é provavelmente a ferramenta mais subutilizada de Git, e simultaneamente a que mais economiza tempo em situações específicas. O cenário: você sabe que algo funcionava ontem e quebrou hoje, mas não sabe qual dos cinquenta commits do dia introduziu o bug. Em vez de inspecionar cada um, bisect faz busca binária:

# Iniciar bisect
git bisect start

# Marcar o commit atual como bom (último que funcionava)
git bisect good v2.3.1

# Marcar o atual como ruim
git bisect bad HEAD

# Git checa out um commit no meio, você testa, e diz:
git bisect good   # ou
git bisect bad

# Repete log_2(N) vezes até identificar o commit culpado
# Para 64 commits = 6 testes; para 1024 commits = 10 testes

Você pode automatizar com git bisect run <script>: o Git checa out cada commit, roda o script, considera passou/falhou pelo exit code. Em casos onde você tem teste reproduzindo o bug, isso é inacreditavelmente eficiente — minutos em vez de horas.

A condição para bisect funcionar bem é que cada commit deveria estar em estado executável e testável. Commits "WIP" quebrados no meio do histórico atrapalham bisect. É uma das razões adicionais para commits atômicos.

git reflog — a rede de segurança

Reflog (reference log) é um histórico local de toda mudança em referências (branches, HEAD). Ele registra cada movimento, mesmo após operações "destrutivas" como reset hard, rebase ou checkout que parecem perder commits. Saber que reflog existe é a diferença entre pânico e calma.

# Ver últimos movimentos
git reflog

# Saída algo como:
abc1234 HEAD@{0}: rebase finished: returning to refs/heads/main
def5678 HEAD@{1}: rebase: pick xyz...
ghi9012 HEAD@{2}: checkout: moving from feature to main
...

# Recuperar commit "perdido"
git checkout def5678
# ou
git reset --hard def5678

Casos clássicos onde reflog salva:

• "Fiz reset hard sem querer e perdi 5 commits". Reflog tem.
• "Rebase deu errado e meu branch ficou estranho". Volte ao estado anterior via reflog.
• "Apaguei branch sem merge". O commit ainda existe; reflog te leva até ele.

Reflog é local — não viaja com push. E entradas eventualmente expiram (default 90 dias para entradas alcançáveis, 30 para não-alcançáveis). Mas enquanto está lá, é seu paraquedas.

Workflows: trunk-based vs Git Flow

Para times maduros com CI/CD funcional, o padrão moderno é trunk-based development: todas as mudanças vão para main rapidamente (horas a poucos dias), via PRs pequenos. Features em desenvolvimento ficam atrás de feature flags. Não há branches de longa vida.

Vantagens: integração contínua de fato, conflitos triviais (não há divergência longa para resolver), deploy contínuo possível, "branches" desnecessários para coordenação.

A alternativa histórica é Git Flow: branches de longa duração (develop, release/*, hotfix/*), cerimônias para mover entre eles. Faz sentido para software com ciclos de release longos (libs públicas, software embarcado, produtos com versionamento explícito). Para a maioria dos times de produto SaaS modernos, é overhead.

A discussão "trunk-based vs Git Flow" frequentemente reflete o estado da maturação de CI/CD do time mais do que preferência abstrata. Se você pode deployar segura e frequentemente (testes verdes, feature flags, monitoramento), trunk-based libera. Se você não pode, Git Flow protege.

Comandos que valem aprender

O Git tem mais de 150 comandos. A maioria você nunca vai usar. Mas há uma faixa intermediária — comandos que não estão entre os 5 primeiros tutoriais, mas que viram cotidiano de quem trabalha bem:

• git diff --staged: ver o que está preparado para o próximo commit (vs git diff que mostra unstaged).
• git add -p: stage parcial. Permite commitar só pedaços de arquivos modificados — fundamental para commits atômicos quando você fez várias mudanças misturadas.
• git stash: guardar mudanças locais temporariamente. git stash pop traz de volta.
• git commit --amend: emendar o último commit (adicionar arquivos esquecidos, corrigir mensagem). Reescreve história — só em commits não-pushados.
• git cherry-pick <sha>: aplicar um commit específico em outra branch. Útil para hotfix em release.
• git log --graph --oneline --all: visão gráfica do histórico. Veja como branches se relacionam.
• git blame: para cada linha de um arquivo, quem foi o último a tocar. Detective work.
• git log -S "termo": pickaxe — busca commits onde o número de ocorrências de "termo" mudou. Achar quando algo foi adicionado ou removido.
• git worktree: ter múltiplos checkouts da mesma repo simultaneamente. Útil para alternar entre features sem commit/stash.

Configurações que mudam tudo

Algumas configurações globais que valem aplicar uma vez:

# Rebase ao puxar, em vez de criar merge commits
git config --global pull.rebase true

# Push só do branch atual
git config --global push.default current

# Cores no diff/log
git config --global color.ui auto

# Comparar com algoritmo melhor (mais legível em refactors)
git config --global diff.algorithm histogram

# Auto-correção de typos em comandos
git config --global help.autocorrect 30   # 3 segundos

# Rerere — lembra resoluções de conflito anteriores
git config --global rerere.enabled true

O último em particular — rerere (reuse recorded resolution) — é mágico: se você já resolveu um conflito uma vez, Git lembra e auto-resolve em rebases futuros do mesmo conflito. Salva tempo em rebases longos.

Como praticar

1. Reescreva a história de uma branch sua. Pegue um branch com 10+ commits "WIP", "fix typo", "more fixes", e use rebase interativo para transformá-lo em 3-4 commits atômicos com mensagens decentes. Exercite squash, fixup, reword.
2. Use bisect num projeto real. Se você não tem bug em mãos, plante um: introduza um defeito 20 commits atrás e use bisect para "encontrar" — mesmo sabendo onde está. A familiaridade com o comando é o ponto.
3. Rastreie a origem de uma linha de código. Pegue um arquivo, escolha uma linha não-trivial. Use git blame + git log -p <arquivo> + git show <sha> para reconstruir a história daquela linha — quem escreveu, em que PR, por que.