Rebase: o que é, como difere do Merge e princípio de funcionamento

O que é Rebase?

Rebase (rebasing) é uma operação do Git que move commits do branch atual para um novo ponto base. Em vez de criar um merge commit, o rebase pega cada commit do branch de origem e o aplica um por um sobre a nova base. O resultado é uma sequência linear de commits sem bifurcações.

O nome rebase vem de “re-base” — mudar a base. Enquanto o merge combina dois branches em um único ponto, o rebase efetivamente move todo o seu branch para um novo local, fazendo parecer que você começou o desenvolvimento a partir do estado atual do branch de destino. Isso cria a ilusão de um trabalho perfeitamente sequencial.

De acordo com a Atlassian, 2025, equipes que usam rebase para branches de feature gastam 30% menos tempo analisando o histórico de commits em comparação com equipes que usam exclusivamente merge. O histórico linear simplifica o git blame, bisect e a visualização do log via git log --oneline.

Diferença fundamental do Merge

Merge une branches criando um commit com dois pais. Rebase reescreve o histórico: novos commits são criados com novos hashes, embora suas alterações sejam idênticas às originais. Isso significa que o rebase altera os identificadores SHA dos commits, o que é crítico para branches públicos.

Como o Rebase funciona

O mecanismo de rebase consiste em quatro etapas: o Git determina o ancestral comum (merge base) do branch atual e do destino, então aplica sequencialmente cada commit do branch atual sobre o branch de destino. Se ocorrer um conflito em qualquer etapa, o rebase para e aguarda resolução.

# Situação inicial: o branch feature está 3 commits atrás do develop
git checkout feature/new-login
git rebase develop

# O Git pega 3 commits da feature e os aplica sobre o develop
# Se não houver conflitos — o rebase é concluído automaticamente
# Se houver — o Git para no commit conflitante

Após o rebase, o branch de feature contém todos os commits do develop mais seus próprios commits, que aparecem como uma continuação do develop. Isso permite mesclar no develop via fast-forward sem criar um merge commit.

Processo passo a passo

Vejamos um exemplo detalhado: um desenvolvedor criou um branch de feature a partir do develop, fez dois commits, enquanto isso outros desenvolvedores adicionaram três commits ao develop. O rebase moverá os dois commits da feature para uma nova posição, criando cópias com novos SHAs.

# 1. Criar um branch feature
git checkout -b feature/payment-refactor develop

# 2. Fazer commits na feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Atualizar o develop (trabalho dos colegas)
git checkout develop
git pull

# 4. Rebase da feature sobre o novo develop
git checkout feature/payment-refactor
git rebase develop

# 5. Agora a feature pode ser mesclada via fast-forward
git checkout develop
git merge feature/payment-refactor

Se ocorrer um conflito na etapa 4, o Git para no commit problemático. O desenvolvedor resolve o conflito, executa git add e depois git rebase --continue. Para pular um commit — git rebase --skip, para cancelar todo o rebase — git rebase --abort.

Pulo automático de commits vazios

A flag --empty controla o comportamento do rebase com commits vazios — situações em que todas as alterações de um commit já estão presentes no branch de destino. Por padrão, o rebase para e pede uma decisão. Com --empty=drop, o Git pula automaticamente esses commits sem parar, acelerando o rebase em massa com um grande número de commits.

Rebase interativo

O rebase interativo (git rebase -i) é uma ferramenta poderosa para editar o histórico de commits. Ele abre um editor com uma lista de commits e comandos-chave: pick (manter), reword (alterar mensagem), edit (alterar conteúdo), squash (mesclar com o anterior), fixup (mesclar sem mensagem), drop (excluir).

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

# O editor abrirá um plano de rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Alteramos para:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Resultado: três commits (tela de login, validação, layout) são mesclados em um, e o commit com comentários é excluído. Isso permite enviar um histórico limpo para revisão de código sem rascunhos e correções. O rebase interativo é uma ferramenta padrão para preparar um branch de feature antes de um Pull Request.

Rebase vs Merge: comparação

Rebase e Merge resolvem o mesmo problema — integrar alterações — mas de maneiras fundamentalmente diferentes. A escolha entre eles depende do tipo de histórico que você quer ver no git log e de quem mais está trabalhando com seu branch.

Regra prática: use merge para integração em branches compartilhados (develop, main) e rebase para atualizar branches de feature pessoais. Muitas equipes combinam ambos: rebase da feature no develop, depois --no-ff merge no develop.

Impacto no git bisect

Git bisect é uma ferramenta para encontrar o commit que introduziu uma regressão. Ao usar merge, o git bisect percorre corretamente os merge commits, considerando ambos os pais. Com rebase, o bisect funciona mais rápido porque o histórico é linear e não requer bifurcações. No entanto, se o rebase foi feito depois que os commits se tornaram conhecidos pela equipe, os SHAs originais são perdidos e o bisect pode não encontrar o commit problemático.

Quando usar Rebase

Rebase é ideal em três cenários: preparar um branch de feature para um Pull Request, atualizar um branch pessoal para o estado atual de main/develop e limpar o histórico antes de mesclar. Em cada caso, o rebase melhora a legibilidade do histórico sem risco para o trabalho em equipe.

Antes de um Pull Request, é recomendado fazer um rebase interativo para combinar commits de rascunho (WIP, correções pós-revisão) em unidades lógicas significativas. Isso facilita a revisão de código: o revisor vê não 15 commits menores, mas 3-5 alterações estruturadas com mensagens claras.

Para atualizar um branch de feature, o rebase é preferível ao merge porque não cria merge commits desnecessários. Se você periodicamente fizer git rebase develop dentro do branch de feature, a mesclagem final não terá uma cascata de 10 merge commits — apenas commits limpos da feature sobre o develop.

A limpeza do histórico via rebase interativo antes de mesclar permite ocultar correções menores (erros de digitação, formatação) e agrupar commits por funcionalidade. As mensagens do Git devem seguir a convenção Conventional Commits (fix:, feat:, refactor:, docs:), que gera um changelog automático.

Riscos e regras do Rebase

Rebase é uma operação perigosa se aplicada incorretamente. O principal risco é reescrever o histórico publicado. Se um desenvolvedor fizer rebase de um branch que outros já enviaram e estão usando, suas cópias locais ficarão dessincronizadas e eles terão que fazer um force-pull com risco de perda de dados.

• Regra de ouro: nunca faça rebase de commits que já existem no repositório compartilhado. Isso se aplica a qualquer branch acessível por outros membros da equipe
• Force push: após rebasar um branch de feature local, é necessário um push com a flag --force-with-lease, que é mais segura que --force porque verifica se alguém atualizou o branch no servidor
• Perda de contexto: o rebase destrói informações sobre quando e de qual branch o branch de feature foi criado. Se preservar as datas de criação do branch é importante, use merge
• Conflitos: durante o rebase, os conflitos devem ser resolvidos para cada commit individualmente, o que pode ser tedioso com um grande número de commits

Para minimizar riscos, siga esta regra: rebase apenas para branches pessoais que não foram publicados. Se um branch já está no repositório compartilhado, use merge com --no-ff. Se precisar rebasar um branch publicado, avise a equipe e coordene o force push com antecedência.

A proteção automática contra rebase perigoso é implementada através de hooks no lado do servidor: um hook pre-receive no servidor Git pode verificar se o push reescreve commits publicados. GitHub e GitLab fornecem proteção integrada para branches protegidos — o force push é bloqueado a menos que um administrador remova a proteção.