Qual é a diferença entre rebase e merge?

Question

Accepted Answer

Ambos **merge** e **rebase** integram mudanças de uma branch em outra, mas fazem isso de formas diferentes: merge **preserva o histórico** com um commit de merge, enquanto rebase **reescreve o histórico** para criar uma sequência linear. Entender a diferença e quando usar cada um é importante.

## Merge — preserva o histórico (combina)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — reescreve para um histórico linear (reproduz)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **move** os commits da sua branch para começarem a partir da ponta de outra branch, criando novos commits — produzindo um histórico limpo e linear.

## A regra de ouro do rebase

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Quando usar cada um

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Por que isso importa

Entender a diferença entre rebase e merge é importante porque ambos integram mudanças mas com efeitos fundamentalmente diferentes no histórico, e escolher corretamente (e com segurança) importa, então é conhecimento Git valioso que também é comumente discutido.

A distinção principal — **merge preserva o histórico** (criando um commit de merge que registra as branches combinadas, mantendo o histórico verdadeiro de desenvolvimento) enquanto **rebase reescreve o histórico** (reproduzindo commits na ponta de outra branch para criar uma sequência limpa e linear como se o trabalho tivesse sido feito no código mais recente) — afeta como o histórico do projeto fica e se lê.

Entender os trade-offs (merge: preciso mas potencialmente poluído com commits de merge; rebase: limpo e linear mas reescrevendo commits) ajuda a escolher com base em se você valoriza o histórico verdadeiro ou a limpeza linear.

Mais criticamente, entender a **regra de ouro do rebase** — **nunca fazer rebase de commits que foram pushed/compartilhados** — é essencial porque rebase reescreve commits (dando-lhes novos hashes), então fazer rebase do histórico compartilhado diverge do que colaboradores têm, causando confusão séria e conflitos; rebase é seguro apenas para commits locais e não-pushados.

Esta regra de segurança é vital e uma fonte comum de problemas quando violada.

Entender **quando usar cada um** (merge para integrar branches compartilhadas e preservar histórico, frequentemente o padrão da equipe para mesclar features via pull requests; rebase para limpar commits locais antes de compartilhar ou manter uma feature branch linealmente atualizada — apenas em commits locais) reflete prática Git sólida.

Como integrar mudanças é fundamental e a escolha merge-vs-rebase (com suas implicações de histórico e segurança) é uma decisão frequente e tópico de entrevista, entender a diferença — seus efeitos no histórico, a regra de ouro crítica, e quando usar cada um — é conhecimento Git valioso, praticamente importante que é central para manter histórico limpo com segurança e uma distinção comumente discutida que todo desenvolvedor deve compreender.