git rebase: reescrever o histórico e quando não usar

git rebase pega commits de uma linha e reaplica suas mudanças sobre outra base. O código final pode coincidir com um merge, mas os commits reaplicados recebem hashes novos. Use para organizar trabalho local ou uma branch de tarefa; não rebase uma história que outras pessoas já puxaram sem coordenação.

O sandbox começou com dois commits na feature:

git --no-pager log --oneline -3

Reaplicar significa criar novos objetos

Enquanto a feature avançava, main recebeu de8696d, uma atualização de documentação. O rebase colocou cada patch da feature depois desse commit:

git rebase main

Pense em retirar duas fichas de uma pilha e preenchê-las novamente sobre uma base atualizada. O texto da mudança pode ser igual, mas data, pai e contexto entram no hash; por isso as fichas novas têm identidades diferentes. O limite é que Git calcula patches e commits, não movimenta papéis literais.

git --no-pager log --oneline -4

Os hashes provam a reescrita

O teste capturou identificadores completos antes e depois:

printf 'antes=%s\ndepois=%s\n' "$ANTES" "$DEPOIS"

Não há apenas abreviação diferente; são objetos diferentes. Uma branch remota que ainda aponta para os antigos enxerga a nova história como não fast-forward.

Merge preserva; rebase redesenha

Merge com divergência cria um commit com dois pais e mantém os hashes das duas linhas. Rebase produz uma sequência linear e recria os commits da branch reaplicada. Nenhum é automaticamente superior. Merge registra como o trabalho aconteceu; rebase pode simplificar a revisão de uma tarefa local.

Use merge quando a bifurcação e a integração têm valor ou quando a história é compartilhada. Use rebase para atualizar sua branch de tarefa antes do PR, quando ninguém baseou trabalho nos seus hashes. O artigo de merge mostra o grafo com dois pais.

Pull rebase evita merges acidentais de atualização

git pull --rebase faz fetch e reaplica seus commits locais sobre o upstream. Ele evita commits “merge main into minha-branch” criados apenas para atualizar. Ainda assim, inspecionar com fetch antes oferece mais controle.

git fetch origin

Depois da inspeção, git rebase origin/main inicia a reaplicação. Um rebase sem conflito informa progresso e sucesso; um comando silencioso deve ser comprovado pelo código de saída e pelo log posterior, não por uma frase inventada.

Conflito no meio aponta qual commit falhou

Quando Refatoração e DDD entraram na mesma região, a execução real parou:

git pull --rebase

O Git está temporariamente em detached HEAD enquanto reaplica. Resolva o arquivo, teste, use git add e continue. --skip descarta o patch atual; só use se você comprovou que a mudança já existe ou não é desejada. --abort volta ao estado anterior ao rebase.

git status --short
sed -n '1,10p' catalogo.txt

Continue uma decisão por vez

Depois de preservar os dois livros:

git add catalogo.txt
GIT_EDITOR=true git rebase --continue

Em rebase com vários commits, outro conflito pode aparecer na próxima aplicação. Não confunda repetição com falha do comando: cada patch encontra uma base nova.

Interativo organiza antes da revisão

git rebase -i BASE abre uma lista em que você pode reordenar, renomear, combinar ou editar commits. Use reword para mensagem, squash ou fixup para combinar e edit para parar. Faça uma branch de segurança e leia o log depois.

git --no-pager reflog -3

Esse formato é o esperado do mecanismo; hashes 02e39a2 e 0cac5b3 vêm do sandbox. O reflog é a referência de recuperação descrita em desfazer no Git.

Nunca rebase o que virou base de outra pessoa

Se alguém puxou seus commits, a pessoa possui os hashes antigos. Rebase publica uma linha paralela e obriga reconciliação. Em branch pessoal de PR, o time pode aceitar atualização com git push --force-with-lease. Lease recusa quando o remote mudou desde sua última observação; --force não oferece essa proteção.

Não rebase main compartilhada. Não use force para resolver o push rejeitado sem entender quem avançou. Sua missão é rebasear dois commits num sandbox, comparar hashes completos e abortar um segundo rebase. Antes de iniciar, crie uma branch de segurança apontando para a ponta atual e anote o upstream. Depois compare o conteúdo com testes, não apenas o formato do grafo. Termine quando você justificar a operação pelo público da branch, não pela aparência linear do log. Se outra pessoa já usa os hashes, pare e combine merge ou uma janela de reescrita; a técnica nunca substitui coordenação.