Git rebase interativo na prática

O problema

Tem gente que usa git rebase -i como se fosse rotina automática.

Tem gente que evita como se fosse dinamite.

Os dois extremos atrapalham.

O medo mais comum vem desta sensação:

• “se eu mexer nisso, vou perder coisa”
• “se eu reescrever commit, vou quebrar a branch”
• “se eu errar, vou apagar trabalho do time”

Boa parte desse medo existe porque o comando costuma ser aprendido como ritual, não como operação concreta sobre histórico.

Modelo mental

Pense assim:

rebase interativo é uma ferramenta para reescrever a história local de commits antes de ela virar contrato com outras pessoas.

Essa frase resolve metade da tensão.

Porque separa dois mundos:

• histórico ainda seu, que você pode organizar
• histórico já compartilhado, onde reescrever custa coordenação

Quando essa fronteira fica clara, o uso fica muito mais saudável.

Quebrando o problema

O que o rebase interativo realmente faz

Ele pega uma sequência de commits e deixa você decidir como essa sequência deve ficar.

Na prática, você pode:

• manter commit como está
• mudar mensagem
• juntar commits
• editar conteúdo no meio
• remover commit ruim
• reordenar a sequência

Ou seja, você não está “mexendo em mágica do Git”.

Está reorganizando commits para que a sequência faça sentido.

O hash muda porque a história mudou

Esse ponto assusta muita gente e é normal.

Quando você faz rebase interativo, os commits resultantes ganham novos hashes.

Não porque o Git quer te punir.

Mas porque um commit é identificado pelo conteúdo e pelo contexto histórico dele.

Se você muda:

• mensagem
• ordem
• parent
• conteúdo

o commit deixa de ser exatamente o mesmo objeto.

O lugar mais seguro para usar é antes de publicar

Esse é o padrão mais importante do artigo.

Rebase interativo costuma ser ótimo para:

• limpar commits locais
• remover “wip”
• juntar ajuste pequeno no commit certo
• deixar review mais legível

Antes de a branch virar referência para mais alguém, o custo é muito menor.

Depois que a branch já está compartilhada, a conversa muda.

Branch compartilhada pede mais cuidado do que coragem

Se outras pessoas já basearam trabalho naquele histórico, reescrever custa coordenação.

Não é “proibido” em qualquer cenário.

Mas precisa ser deliberado.

Sem isso, você cria:

• divergência desnecessária
• force push confuso
• branch quebrada para outra pessoa

O problema aqui não é o rebase.

É a falta de acordo.

Os comandos principais são menos complicados do que parecem

Os que mais importam no dia a dia são:

• pick: mantém
• reword: mantém conteúdo e muda mensagem
• squash: junta com commit anterior e reabre mensagem
• fixup: junta com commit anterior sem abrir edição de mensagem
• edit: pausa para você mudar algo
• drop: remove aquele commit da sequência

Na prática, muita gente já resolve 80% do caso real com:

• reword
• squash
• fixup

Histórico limpo não é só estética

Review melhora quando a sequência de commits conta uma história decente.

Debug melhora quando você consegue entender intenção.

Cherry-pick e investigação melhoram quando o ruído está menor.

Então sim, tem valor real.

Só não vale transformar isso em culto.

Exemplo simples

Imagine uma branch com estes commits:

1. adiciona validacao
2. wip
3. corrige typo
4. ajusta teste
5. agora vai

Isso funciona?

Funciona.

Mas para review e histórico, está ruim.

Com rebase interativo você pode transformar em algo como:

1. adiciona validacao de payload no endpoint de pedidos
2. ajusta testes para o novo comportamento

Mesma mudança essencial.

História muito mais legível.

O ganho não é vaidade.

É reduzir ruído para a próxima pessoa, inclusive você.

Erros comuns

• Fazer rebase interativo em branch já compartilhada sem alinhar com ninguém.
• Usar drop sem entender o que realmente está removendo.
• Tratar force push como detalhe irrelevante depois de reescrever histórico.
• Tentar deixar o histórico “artístico” e gastar mais tempo nisso do que no código.
• Fugir completamente da ferramenta e empilhar commits confusos por medo.

Como um senior pensa

Quem tem mais experiência normalmente não pergunta:

“Rebase é bom ou ruim?”

Pergunta algo melhor:

“Este histórico ainda é meu para organizar ou já virou superfície compartilhada com outras pessoas?”

Essa pergunta muda o comportamento.

Porque puxa a decisão para colaboração e custo de coordenação.

Senioridade aqui não aparece em decorar comando exótico.

Aparece em saber limpar o que precisa e parar onde o risco de coordenação começa.

O que o entrevistador quer ver

Em entrevista, esse tema mede mais colaboração e modelo mental do que Git avançado.

O avaliador quer perceber se você entende:

• o que é reescrever histórico
• quando isso é seguro
• quando isso complica o trabalho dos outros
• por que histórico limpo ajuda sem virar obsessão

Uma resposta forte pode soar assim:

“Eu gosto de usar rebase interativo principalmente antes de publicar a branch, para limpar commits locais, juntar ruído e deixar o review mais claro. Depois que a branch está compartilhada, eu só reescrevo histórico com coordenação explícita, porque o custo deixa de ser técnico e passa a ser colaborativo.”

Rebase interativo não destrói a empresa. Reescrever histórico compartilhado sem combinar é que chega mais perto disso.

O uso maduro do Git não está em ter medo. Está em saber onde o comando termina e onde começa a coordenação com outras pessoas.