ArtigoDev

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.

Por João Megale··2 min de leitura
Imagem de capa: Git rebase sem medo: o modelo mental que faltava

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.

#git#versionamento#workflow

Relacionados