Git rebase sem medo: o modelo mental que faltava
Rebase parece bruxaria até você entender que é só reaplicar commits. O modelo mental, os comandos essenciais e a regra de ouro do histórico.

Poucos comandos do Git causam tanto pavor quanto o rebase. A fama é de perigoso, irreversível, coisa de quem já quebrou o repositório uma vez. A verdade é mais simples — e mais tranquilizadora: rebase é só pegar seus commits e reaplicá-los sobre outra base. Entendido o conceito, o medo evapora.
O modelo mental
Imagine que sua branch nasceu de um ponto antigo da main. Enquanto você trabalhava, a main andou — outras pessoas fizeram merge. Agora seu histórico está “desalinhado”.
O merge resolve isso criando um commit de junção (e um histórico em forma de teia). O rebase resolve de outro jeito: ele finge que você começou a trabalhar agora. Pega cada commit seu, um por um, e reaplica sobre o topo atual da main. O resultado é um histórico linear, como se você tivesse acabado de sair da versão mais recente.
git switch minha-feature
git rebase main
Quando dá conflito
Como o Git reaplica commit a commit, um conflito para o processo naquele commit específico. Você resolve, marca como resolvido e manda continuar:
# edite os arquivos em conflito, depois:
git add arquivo-resolvido.ts
git rebase --continue
Quer desistir e voltar tudo ao estado anterior? Um comando:
git rebase --abort
A regra de ouro (a parte que importa)
Aqui está o que separa quem usa rebase com segurança de quem estraga o dia do time:
- ✅ Use em commits locais, que só existem na sua máquina — antes de abrir o PR, para limpar o histórico.
- ✅ Use para atualizar sua branch com o que entrou na
main. - ❌ Nunca reescreva histórico de uma branch compartilhada que outras pessoas já puxaram. Rebase reescreve commits (muda os hashes); se alguém já baseou trabalho neles, você cria um caos de divergência.
A regra em uma frase: rebase o que é seu e privado; nunca o que já é público e compartilhado.
A rede de segurança que ninguém conta
O que torna o rebase menos assustador é saber que o Git quase nunca perde nada de verdade — só reorganiza. E o reflog guarda por onde você passou:
git reflog
# acha o estado anterior, ex: HEAD@{3}
git reset --hard HEAD@{3}
Errou feio no rebase? O reflog é a sua máquina do tempo. Enquanto o commit existiu em algum momento, ele está recuperável por dias.
Conclusão
Rebase deixa de ser bruxaria quando você percebe duas coisas: é só reaplicar commits, e nada é perdido de verdade — só rearranjado. Pratique num branch de teste, use o --abort sem culpa, e respeite a regra de ouro. Em uma semana, você vai preferir o histórico linear que ele entrega.