Qual è la differenza tra rebase e merge?

Question

Accepted Answer

Sia **merge** che **rebase** integrano i cambiamenti da un ramo a un altro, ma lo fanno diversamente: merge **preserva la cronologia** con un commit di merge, mentre rebase **riscrive la cronologia** per creare una sequenza lineare. Comprendere la differenza e quando usare ciascuno è importante.

## Merge — preserva la cronologia (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 — riscrive per una cronologia lineare (riproduce)

```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 **sposta** i commit del tuo ramo per iniziare dal tip di un altro ramo, creando nuovi commit — producendo una cronologia pulita e lineare.

## La regola d'oro del rebasing

```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 usare ciascuno

```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.
```

## Perché è importante

Comprendere la differenza tra rebase e merge è importante perché entrambi integrano i cambiamenti ma con effetti fondamentalmente diversi sulla cronologia, e scegliere correttamente (e in modo sicuro) è importante, quindi è una conoscenza di Git preziosa che è anche comunemente discussa.

La distinzione fondamentale — **merge preserva la cronologia** (creando un commit di merge che registra i rami combinati, mantenendo la vera cronologia dello sviluppo) mentre **rebase riscrive la cronologia** (riproducendo i commit sul tip di un altro ramo per creare una sequenza pulita e lineare come se il lavoro fosse stato fatto sul codice più recente) — influisce sull'aspetto e sulla leggibilità della cronologia del progetto.

Comprendere i compromessi (merge: accurato ma potenzialmente ingombro di commit di merge; rebase: pulito e lineare ma riscrivendo i commit) aiuta a scegliere in base a se valuti la vera cronologia o la pulizia lineare.

Così come è essenziale comprendere la **regola d'oro del rebasing** — **non fare mai rebase di commit che sono stati pushed/condivisi** — è essenziale perché rebase riscrive i commit (assegnando loro nuovi hash), quindi fare rebase della cronologia condivisa diverge da ciò che i collaboratori hanno, causando seri conflitti e confusione; rebase è sicuro solo per i commit locali non pushati.

Questa regola di sicurezza è vitale e una fonte comune di problemi quando violata.

Comprendere **quando usare ciascuno** (merge per integrare rami condivisi e preservare la cronologia, spesso il default del team per unire le funzionalità via pull request; rebase per pulire i commit locali prima di condividerli o per mantenere un ramo di funzionalità linealmente aggiornato — solo su commit locali) riflette una pratica Git corretta.

Poiché integrare i cambiamenti è fondamentale e la scelta merge-vs-rebase (con le sue implicazioni di cronologia e sicurezza) è una decisione frequente e un argomento di intervista, comprendere la differenza — i loro effetti sulla cronologia, la regola d'oro critica, e quando usare ciascuno — è una conoscenza Git preziosa e praticamente importante che è centrale per mantenere una cronologia pulita in modo sicuro e una distinzione comunemente discussa che ogni sviluppatore dovrebbe comprendere.