Gerador de comando git rebase

Git rebase em profundidade: reescrita de histórico, modo interativo e armadilhas em branches compartilhadas

O git rebase é um dos comandos mais poderosos — e mais mal compreendidos — do Git. Enquanto o git merge integra dois históricos criando um commit de merge, o git rebase reescreve o histórico pegando seus commits e re-aplicando um a um sobre uma base diferente. O resultado é um histórico linear, "como se você nunca tivesse criado uma branch". Linus Torvalds introduziu o conceito ainda no plumbing original do Git em 2005; o modo interativo moderno, que permite squash, reordenação e edição de commits, surgiu logo depois e hoje é a espinha dorsal dos workflows de PR limpos no GitHub, GitLab e Bitbucket.

Este gerador produz comandos de rebase prontos para colar (rebase em cima de main, limpeza interativa, transplante de commits com --onto, autosquash de fixups). Abaixo você encontra uma referência completa sobre o algoritmo, os verbos interativos, as diferenças entre workflows de merge e rebase e as técnicas de recuperação quando algo dá errado.

Anatomia do rebase: como o Git reaplica seus commits

Um rebase percorre os commits únicos da sua branch (aqueles que não estão na nova base) em ordem e, para cada um, cria um novo commit com a mesma árvore em cima da nova base. Como o hash do pai muda, cada commit reaplicado ganha um SHA totalmente novo, mesmo que o diff seja idêntico byte a byte.

git rebase main              # reaplica a branch atual em cima de main
git rebase -i HEAD~5         # interativo: edita os últimos 5 commits
git rebase --onto target old new   # move commits entre old..new para target
git rebase --root            # rebase desde o primeiríssimo commit
git rebase --continue        # depois de resolver um conflito
git rebase --abort           # cancela e restaura a branch original
git rebase --skip            # descarta o commit atual e segue em frente

Verbos interativos: pick, reword, edit, squash, fixup, drop, exec

• pick — mantém o commit como está.
• reword — mantém as mudanças mas abre o editor para alterar a mensagem.
• edit — para após aplicar para você poder fazer amend, dividir ou reorganizar arquivos.
• squash (ou s) — funde o commit ao anterior e combina as duas mensagens.
• fixup (ou f) — igual ao squash, mas descarta a mensagem deste commit.
• drop (ou d) — remove o commit por completo. Apagar a linha equivale ao mesmo efeito.
• exec — executa um comando shell arbitrário depois do commit (ótimo para rodar npm test entre commits).
• reorder — basta rearranjar as linhas da lista para mudar a ordem dos commits.

Rebase vs merge: qual workflow escolher?

Merge preserva a topologia real — dá para ver quais commits nasceram numa feature branch e quando foram integrados. O histórico é honesto, mas pode ficar barulhento com "bolhas" de merge. Rebase reescreve tudo em uma linha reta, mais fácil de inspecionar com git log --oneline e usar git bisect, mas o contexto original do branching se perde.

Na prática três filosofias dominam: GitHub flow adota commits de merge (ou "squash merge", que achata um PR em um único commit); GitLab flow e a lista do kernel Linux preferem rebasear sobre o alvo antes de mergear; equipes que seguem Conventional Commits costumam rebasear + squash interativo para que todo commit em main seja significativo e atômico.

Autosquash, autostash e rerere — as opções de usuário avançado

--autosquash se combina com commits prefixados fixup! ou squash! (gerados por git commit --fixup=<sha>). Quando você roda git rebase -i --autosquash HEAD~10 mais tarde, o Git reordena a lista para que cada fixup fique abaixo do seu alvo com o verbo correto já preenchido — sem edição manual.

--autostash guarda automaticamente as alterações não comitadas antes do rebase e as devolve depois, sem interromper o seu trabalho em andamento. Ative globalmente com git config rebase.autoStash true.

git config rerere.enabled true liga o "reuse recorded resolution" — o Git memoriza como você resolveu um conflito e reaplica a resolução automaticamente quando o mesmo conflito aparece de novo. Imprescindível em rebases longos e em branches que são rebaseadas várias vezes.

Armadilhas em branches compartilhadas e recuperação

A regra de ouro: nunca rebaseie uma branch que já foi enviada e em que outras pessoas estão trabalhando. Como o rebase reescreve SHAs, o próximo git push exige --force (ou o mais seguro --force-with-lease), e quem tinha os commits antigos precisa se recuperar à mão. A exceção é a sua própria branch de feature em um PR: force-push lá tudo bem, idealmente depois das aprovações para revisores não perderem o contexto.

Conflitos podem aparecer uma vez por commit reaplicado — às vezes o mesmo conflito surge três ou quatro vezes durante um único rebase. Depois de corrigir os arquivos, git add e rode git rebase --continue. Não faça git commit manualmente no meio do rebase; o maquinário cria o commit por você.

Recuperação: o reflog do Git guarda toda posição que o HEAD ocupou nos últimos 90 dias por padrão. Perdeu um commit depois de um rebase ruim? Rode git reflog, ache o SHA desejado e use git reset --hard <sha> para restaurar ou git cherry-pick <sha> para trazê-lo à frente. O ORIG_HEAD aponta automaticamente para o ponto onde a branch estava antes do rebase começar — git reset --hard ORIG_HEAD desfaz a operação em um passo só.

FAQ

Dá para desfazer um rebase? Sim. Rode git reflog, localize a entrada logo antes de "rebase (start)" e use git reset --hard HEAD@{N}. Em até 90 dias os commits originais continuam no banco de objetos, mesmo que nenhuma branch aponte para eles.

Devo rebasear meu PR antes de mergear? Depende da equipe. Muitos times exigem rebase sobre a main mais recente para o PR fechar com fast-forward; outros adotam "squash and merge", que dribla a questão. Faça force-push apenas depois das aprovações para revisores não perderem o lugar.

Rebase ou merge — qual usar sempre? Nenhum dos dois em absoluto. Rebase para branches de feature em andamento que só você toca; merge (ou squash-merge) quando integrar trabalho finalizado nos troncos compartilhados. O pior é misturar estratégias na mesma branch.

O que acontece com commits de merge quando faço rebase? Por padrão eles são achatados e reescritos como commits comuns. Use --rebase-merges (ou -r) para preservar a topologia — útil ao integrar várias sub-branches.

Como rebasear só os últimos commits sem mexer no histórico antigo? Use git rebase -i HEAD~N, onde N é o número de commits a incluir. O Git reaplica essa fatia na mesma base, então o ponto de integração com a main não muda — apenas os seus commits locais ganham novos SHAs.