Koja je razlika između rebase i merge?

Question

Accepted Answer

Oba **merge** i **rebase** integriraju promjene iz jedne grane u drugu, ali to čine različito: merge **čuva historiju** s merge commit-om, dok rebase **prepisuje historiju** da bi se stvorila linearna sekvenca. Razumijevanje razlike i kada koristiti svaki je važno.

## Merge — čuva historiju (kombinira)

```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 — prepisuje za linearnu historiju (ponavlja)

```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 **premješta** commit-e vaše grane da počnu od vrha druge grane, stvarajući nove commit-e — što proizvodi čistu, linearnu historiju.

## Zlatno pravilo rebasiranja

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

## Kada koristiti svaki

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

## Zašto je to važno

Razumijevanje razlike između rebase i merge je važno jer oba integriraju promjene, ali sa fundamentalno različitim učincima na historiju, a izbor koji je ispravan (i siguran) je bitan, zato je to dragocjeno Git znanje koje se često raspravlja.

Osnovnu razliku — **merge čuva historiju** (stvarajući merge commit koji bilježi kombiniranje grana, čuvajoći pravu historiju razvoja) nasuprot **rebase koja prepisuje historiju** (ponavljajući commit-e na vrh druge grane da bi se kreirala čista, linearna sekvenca kao da je rad obavljen na najnovijoj kodu) — utječe na izgled i čitljivost historije projekta.

Razumijevanje kompromisa (merge: točan ali potencijalno zagušen merge commit-ima; rebase: čist i linearan, ali prepisuje commit-e) pomaže u izboru ovisno o tome vrijedite li pravu historiju ili linearnu čistoću.

Najkritičnije, razumijevanje **zlatnog pravila rebasiranja** — **nikada ne rebasirajte commit-e koji su objavljeni/dijeljeni** — je bitno jer rebase prepisuje commit-e (dajući im nove hash-eve), pa rebasiranje dijeljene historije divergira od onoga što suradnici imaju, što uzrokuje ozbiljnu zbrku i konflikte; rebase je siguran samo za lokalne, neobjavljene commit-e.

Ovo pravilo sigurnosti je vitalno i čest izvor problema kada se prekrši.

Razumijevanje **kada koristiti svaki** (merge za integriranje dijeljenih grana i čuvanje historije, često timska zadana opcija za spajanje značajki putem pull request-a; rebase za čišćenje lokalnih commit-a prije diobi ili održavanje grane značajke linearnom ažuriranošću — samo na lokalnim commit-ima) odražava zvučnu Git praksu.

Budući da je integriranje promjena fundamentalno i izbor između merge-a i rebase-a (sa njegovim implikacijama za historiju i sigurnost) česta odluka i tema intervjua, razumijevanje razlike — njihov utjecaj na historiju, kritično zlatno pravilo i kada koristiti svaki — je dragocjeno, praktično-važno Git znanje koje je ključno za održavanje čiste historije sigurno i uobičajena je razlika koju bi svaki razvojni inženjer trebao razumjeti.