Kakšna je razlika med rebase in merge?

Question

Accepted Answer

Oba **merge** in **rebase** integrirajo spremembe iz ene veje v drugo, vendar to storijo drugače: merge **ohrani zgodovino** z merge commitom, medtem ko rebase **prepiše zgodovino** za ustvarjanje linearne sekvence. Razumevanje razlike in kdaj uporabiti vsakega je pomembno.

## Merge — ohrani zgodovino (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 — prepiše za linearno zgodovino (ponovno preslika)

```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 **premakne** committe vaše veje tako, da se začnejo na vrhu druge veje, kar ustvari nove committe — kar daje čisto, linearno zgodovino.

## Zlato pravilo 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.
```

## Kdaj uporabiti vsakega

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

## Zakaj je to pomembno

Razumevanje razlike med rebase in merge je pomembno, ker oba integrirajo spremembe, vendar s fundamentalno različnimi učinki na zgodovino, in pravilna izbira (in varna) je pomembna, zato je to dragoceno Git znanje, ki se pogosto razpravlja.

Osrednja razlika — **merge ohrani zgodovino** (ustvari merge commit, ki beleži kombinirane veje, in ohrani pravo razvojno zgodovino) medtem ko **rebase prepiše zgodovino** (ponovno preslikuje committe na vrh veje druge veje, da ustvari čisto, linearno sekvenco, kot da bi bila dela narejena na najnovejši kodi) — vpliva na to, kako izgledajo razvojni spremembe in kako jih je vredno brati.

Razumevanje kompromisov (merge: natančen, vendar potencialno neuredan z merge committi; rebase: čist in linearen, vendar prepisuje committe) pomaga izbrati glede na to, ali cenite pravo zgodovino ali linearno čistost.

Najkriličnije je razumevanje **zlatega pravila rebasing** — **nikoli ne rebasirajte commitov, ki so bili poslani/deljeni** — ker je to bistveno, saj rebase prepiše committe (jim da nove hešeje), zato rebase deljene zgodovine divergira od tega, kar imajo sodelavci, in povzroči resne težave in konflikte; rebase je varen le za lokalne, neobjavljene committe.

To pravilo varnosti je ključno in pogost vir težav, ko se krši.

Razumevanje **kdaj uporabiti vsakega** (merge za integracijo deljenih vej in ohranitev zgodovine, pogosto privzeta izbira ekipe za spajanje funkcij prek pull requestov; rebase za čiščenje lokalnih commitov pred dejenjem ali vzdrževanje veje funkcije linearno posodobljene — samo na lokalnih commitih) odraža dobro Git prakso.

Ker je integracijo sprememb temeljno in je izbira merge-vs-rebase (z njenimi učinki na zgodovino in varnost) pogosta odločitev in tema pogovora, je razumevanje razlike — njihovega učinka na zgodovino, kritičnega zlatega pravila in kdaj uporabiti vsakega — dragoceno, praktično pomembno Git znanje, ki je osrednje za vzdrževanje čiste zgodovine na varen način in pogosto razpravljana razlika, ki jo bi moral razumeti vsak razvijalec.