Jaký je rozdíl mezi rebase a merge?

Question

Accepted Answer

Jak **merge**, tak **rebase** integrují změny z jedné větve do druhé, ale dělají to různě: merge **zachovává historii** s merge commitem, zatímco rebase **přepisuje historii** a vytváří lineární sekvenci. Pochopení rozdílu a kdy použít který je důležité.

## Merge — zachovává historii (kombinuje)

```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 — přepisuje pro lineární historii (přehrává)

```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 **přesune** commity vaší větve tak, aby začínaly od špičky jiné větve, vytváří nové commity — výsledkem je čistá, lineární historie.

## Zlaté pravidlo 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.
```

## Kdy použít který

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

## Proč je to důležité

Pochopení rozdílu mezi rebase a merge je důležité, protože oba integrují změny, ale se fundamentálně odlišnými důsledky na historii, a správná (a bezpečná) volba záleží, takže je to cenné Git vědění, které se také často diskutuje.

Jádnový rozdíl — **merge zachovává historii** (vytváří merge commit, který zaznamenává, že se větve spojily, zachovává skutečnou historii vývoje), zatímco **rebase přepisuje historii** (přehrává commity na špičku druhé větve, aby se vytvořila čistá, lineární sekvence, jako by práce probíhala na nejnovějším kódu) — ovlivňuje, jak projekt vypadá a čte se jeho historii.

Pochopení kompromisů (merge: přesný, ale potenciálně chaotický s merge commity; rebase: čistý a lineární, ale přepisuje commity) pomáhá zvolit na základě toho, zda si cените skutečnou historii nebo lineární čistotu.

Nejkritičtěji je pochopení **zlatého pravidla rebasing** — **nikdy nerebujte commity, které byly pushnuty/sdíleny** — zásadní, protože rebase přepisuje commity (dávají jim nové hashe), takže rebase sdílené historie se rozchází s tím, co mají kolaborátoři, způsobuje vážné zmatky a konflikty; rebase je bezpečný pouze pro lokální, nepushnuté commity.

Toto bezpečnostní pravidlo je životně důležité a časté zdroje problémů, když je porušeno.

Pochopení **kdy použít který** (merge pro integraci sdílených větví a zachování historie, často výchozí volba týmu při slučování funkcí přes pull requesty; rebase pro čištění lokálních commitů před sdílením nebo udržení větvě funkcí lineárně aktuální — pouze na lokálních commitech) odráží správnou Git praxi.

Protože integrace změn je fundamentální a volba merge versus rebase (s jejími důsledky na historii a bezpečnost) je časté rozhodnutí a téma na rozhovorech, pochopení rozdílu — jejich efekty na historii, kritické zlaté pravidlo a kdy použít který — je cenné, prakticky důležité Git vědění, které je ústředním prvkem udržování čisté historie bezpečně a běžně diskutovaným rozdílem, kterému by měl rozumět každý vývojář.