Care este diferența dintre rebase și merge?

Question

Accepted Answer

Atât **merge** cât și **rebase** integrează schimbările dintr-o ramură în alta, dar o fac diferit: merge **păstrează istoria** cu un commit de merge, în timp ce rebase **rescrie istoria** pentru a crea o secvență liniară. Înțelegerea diferenței și când să folosești fiecare este importantă.

## Merge — păstrează istoria (combină)

```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 — rescrie pentru o istorie liniară (redă)

```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 **mută** commits-urile ramturii tale pentru a începe de la vârful unei alte ramuri, creând commits-uri noi — producând o istorie curată și liniară.

## Regula de aur a 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.
```

## Când să folosești fiecare

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

## De ce contează

Înțelegerea diferenței dintre rebase și merge este importantă deoarece ambele integrează schimbări, dar cu efecte fundamental diferite asupra istoriei, iar alegerea corectă (și sigură) contează, deci este o cunoaștere Git valoroasă care este și discutată frecvent.

Distincția esențială — **merge păstrează istoria** (creând un commit de merge care înregistrează ramurile combinate, păstrând adevărata istorie de dezvoltare) în timp ce **rebase rescrie istoria** (redând commits pe vârful altei ramuri pentru a crea o secvență curată și liniară ca și cum munca ar fi fost făcută pe codul cel mai recent) — afectează cum arată și cum se citește istoricul proiectului.

Înțelegerea compromisurilor (merge: precis dar potențial aglomerat cu commits de merge; rebase: curat și liniar dar rescriind commits-uri) ajută la alegere pe baza dacă valori adevărata istorie sau curățenia liniară.

Cel mai critic, înțelegerea **regulei de aur a rebasing** — **nu face rebase pe commits care au fost pushed/partajate** — este esențială deoarece rebase rescrie commits-uri (dând-le hash-uri noi), deci rebasing-ul istoriei partajate diverge de ceea ce au colaboratorii, cauzând confuzie și conflicte serioase; rebase este sigur doar pentru commits-uri locale, nepushate.

Această regulă de siguranță este vitală și o sursă comună de probleme când este încălcată.

Înțelegerea **când să folosești fiecare** (merge pentru integrarea ramurilor partajate și păstrarea istoriei, adesea valoarea implicită a echipei pentru merge-ul caracteristicilor prin pull requests; rebase pentru curățarea commits-urilor locale înainte de a partaja sau ținând o ramură de caracteristici actualizată liniar — doar pe commits-uri locale) reflectă practica Git sănătoasă.

Dintru că integrarea schimbărilor este fundamentală și alegerea merge-vs-rebase (cu implicațiile sale asupra istoriei și securității) este o decizie frecventă și subiect de interviu, înțelegerea diferenței — efectele lor asupra istoriei, regula critică de aur și când să folosești fiecare — este o cunoaștere Git valoroasă și practic-importantă care este centrală în menținerea unei istorii curate și sigure și o distincție frecvent-discutată pe care fiecare developer ar trebui s-o înțeleagă.