Git Rebase vs Merge: guia completo com exemplos reais e quando usar cada um

Ogit rebase vs mesclagem O debate é uma das questões mais comuns sobre fluxo de trabalho que os desenvolvedores enfrentam. Ambos integram mudanças de uma ramificação para outra — mas fazem isso de maneira diferente, deixam histórias diferentes e têm casos de uso apropriados diferentes. Este guia cobre ambos os comandos com exemplos reais para que você saiba exatamente quando usar cada um.

A principal diferença

mesclar git cria um commit de mesclagem que une dois históricos de ramificação. O histórico registra que ocorreu uma mesclagem – não destrutivo, preserva o contexto.

git rebase reproduz seus commits em cima de outro branch, reescrevendo o histórico de commits para parecer que você ramificou a partir do ponto mais recente. Cria um histórico linear — sem commits de mesclagem.

# Starting state:
#   A---B---C  main
#        #         D---E  feature

# After git merge:
#   A---B---C---F  main  (F = merge commit)
#              /
#         D---E  feature

# After git rebase:
#   A---B---C---D'---E'  main  (D', E' = replayed commits with new hashes)

git merge — Preserva a verdadeira história

# Merge feature into main
git checkout main
git merge feature

# Creates a merge commit:
# Merge branch 'feature' into main
# (includes all commits from feature branch)

# Fast-forward merge (no merge commit if possible)
git merge --ff-only feature

Use mesclar quando:

• Mesclando uma ramificação de recurso concluída em main/master
• Trabalhando em ramificações públicas/compartilhadas (nunca rebase estas)
• Você deseja que o histórico mostre que ocorreu uma mesclagem
• Resolver conflitos uma vez é melhor do que resolvê-los commit por commit

git rebase — Cria histórico linear

# Rebase feature onto main (move feature's commits on top of main)
git checkout feature
git rebase main

# Now feature contains main's latest commits + your commits on top
# Switch to main and fast-forward merge
git checkout main
git merge feature  # fast-forward, no merge commit

Use rebase quando:

• Atualizando umlocais feature branch com as últimas alterações do main antes de abrir um PR
• Limpando o histórico de commits antes de mesclar (esmagando commits de correção)
• Você quer um log git limpo e linear

A Regra de Ouro — Nunca Rebase Branches Compartilhados

Rebase reescreve hashes de commit. Se você fizer o rebase de um branch que seus colegas fizeram check-out, suas cópias locais terão hashes de commit diferentes — criando uma divergência de pesadelo.

# NEVER do this:
git checkout main
git rebase feature  # rewrites main's history — everyone's fork breaks

# SAFE: only rebase your local feature branch
git checkout feature      # your private branch
git rebase main           # safe — nobody else has this branch

Rebase interativo — Limpando seu histórico

Rebase interativo (git rebase -i) permite editar, compactar, reordenar ou eliminar commits antes de mesclar. Essencial para solicitações pull limpas.

# Squash last 3 commits into one
git rebase -i HEAD~3

# Opens an editor showing:
# pick a1b2c3 Add user login endpoint
# pick d4e5f6 fix typo
# pick g7h8i9 fix linting errors

# Change to:
# pick a1b2c3 Add user login endpoint
# squash d4e5f6 fix typo
# squash g7h8i9 fix linting errors

# Result: one clean commit "Add user login endpoint"

Comandos de rebase interativos:

Lidando com Conflitos de Rebase

# Rebase stopped due to conflict
git rebase main
# CONFLICT in app/models.py
# Auto-merging app/models.py
# error: could not apply a1b2c3... Add user model

# Fix the conflict in your editor, then:
git add app/models.py
git rebase --continue

# If things get messy, abort entirely:
git rebase --abort

Ao contrário dos conflitos de mesclagem (resolvidos uma vez), os conflitos de rebase podem ocorrer por commit — um dos motivos pelos quais a mesclagem às vezes é preferível para ramificações de longa execução com muitos commits.

Recomendações de fluxo de trabalho do mundo real

Para um fluxo de trabalho típico de ramificação de recurso:

# 1. Create feature branch
git checkout -b feature/user-auth

# 2. Work on your feature, commit frequently
git commit -m "wip: add login form"
git commit -m "fix: validation edge case"

# 3. Before opening PR: clean up and update
git fetch origin
git rebase origin/main          # get latest main
git rebase -i origin/main       # squash WIP commits

# 4. Push and open PR
git push -f origin feature/user-auth  # force push after rebase is OK on your own branch

# 5. After approval: merge into main (via PR)
# Use squash-and-merge or merge commit in GitHub/GitLab

Árvore de decisão de mesclagem vs rebase

• Esta é uma filial pública/compartilhada? →Sempre mescle, nunca faça rebase
• Atualizando sua ramificação de recurso local com main? →Rebase
• Mesclando o recurso concluído no principal? →Mesclar (preserva o contexto)
• Limpando commits WIP antes de um PR? →Rebase interativo
• A equipe prefere história linear? →Rebase para ramificações de recursos, mesclagem para integração

Perguntas Frequentes

P: Minha equipe precisa chegar a um acordo sobre uma estratégia?
R: Sim. Misturar mesclagem e rebase cria aleatoriamente um histórico confuso. Escolha uma abordagem e documente-a em seu CONTRIBUTING.md.

P: git merge –squash é o mesmo que squash rebase?
R: Resultado semelhante (um commit limpo), mas mecânica diferente. --squash cria uma única alteração não confirmada que você confirma manualmente. O rebase do squash reescreve o histórico da ramificação diretamente.

P: Devo usar git pull –rebase?
R: Muitas equipes configuram isso como padrão (git config --global pull.rebase true). Ele evita commits de mesclagem desnecessários durante o pull – geralmente mais limpo para equipes de ritmo acelerado.

P: O que acontece com os commits originais após o rebase?
R: Eles não são excluídos imediatamente — eles se tornam commits pendentes. A coleta de lixo do Git os remove após aproximadamente 30 dias. Usargit reflog para recuperá-los, se necessário.

P: Como faço para desfazer um rebase?
A: git reflog mostra seu histórico de posições HEAD. Encontre o hash de commit antes do rebase e entãogit reset --hard HASH. Isso funciona desde que você não tenha enviado publicamente o branch rebaseado.

Conclusão

Use mesclagem para integrar ramificações concluídas e preservar o contexto do histórico. Use rebase para manter seu branch de recursos atualizado e para limpar commits antes da revisão. A regra mais importante: nunca rebase as ramificações a partir das quais outras pessoas estão trabalhando. Além disso, a escolha depende da preferência da sua equipe pela legibilidade do histórico. Ambos os comandos são habilidades essenciais para qualquer desenvolvedor que trabalhe em uma equipe real.