Jaka jest różnica między rebase a merge?

Question

Accepted Answer

Zarówno **merge** jak i **rebase** integrują zmiany z jednej gałęzi do drugiej, ale robią to w różny sposób: merge **zachowuje historię** z commitem merge, podczas gdy rebase **przepisuje historię**, aby utworzyć liniową sekwencję. Zrozumienie różnicy i kiedy użyć każdego z nich jest ważne.

## Merge — zachowuje historię (łączy)

```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 — przepisuje do uzyskania liniowej historii (odtwarza)

```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 **przenosi** commity twojej gałęzi, aby zaczynały się od czubka innej gałęzi, tworząc nowe commity — produkując czystą, liniową historię.

## Złota reguła rebase

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

## Kiedy używać każdego z nich

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

## Dlaczego to ważne

Zrozumienie różnicy między rebase a merge jest ważne, ponieważ oba integrują zmiany, ale z fundamentalnie różnymi efektami na historię, a wybór poprawny (i bezpieczny) ma znaczenie, dlatego jest to cenna wiedza na temat Gita, która jest również powszechnie omawiana.

Kluczowa różnica — **merge zachowuje historię** (tworząc commit merge, który rejestruje połączone gałęzie, zachowując prawdziwą historię rozwoju) podczas gdy **rebase przepisuje historię** (odtwarzając commity na czubku innej gałęzi, aby utworzyć czystą, liniową sekwencję, jakby praca została wykonana na najnowszym kodzie) — wpływa na to, jak wygląda i czyta się historia projektu.

Zrozumienie kompromisów (merge: dokładne, ale potencjalnie zaśmiecone commitami merge; rebase: czyste i liniowe, ale przepisujące commity) pomaga wybrać na podstawie tego, czy ceniasz prawdziwą historię czy liniową czystość.

Najkrytyczniej, zrozumienie **złotej reguły rebase** — **nigdy nie wykonuj rebase commitów, które zostały push/udostępnione** — jest niezbędne, ponieważ rebase przepisuje commity (dając im nowe hashe), więc rebase udostępnionej historii rozbieżnie się z tym, co mają współpracownicy, powodując poważne zamieszanie i konflikty; rebase jest bezpieczny tylko dla lokalnych, nie-push commitów.

Ta reguła bezpieczeństwa jest istotna i częstym źródłem problemów, gdy jest naruszana.

Zrozumienie **kiedy używać każdego z nich** (merge do integrowania udostępnionych gałęzi i zachowywania historii, często zespołowy domyślnie dla mergowania funkcji poprzez pull requesty; rebase do czyszczenia lokalnych commitów przed udostępnieniem lub utrzymywania gałęzi funkcji liniowo na bieżąco — tylko na lokalnych commitach) odzwierciedla dobre praktyki Gita.

Ponieważ integrowanie zmian jest fundamentalne, a wybór merge-vs-rebase (z jego skutkami dla historii i bezpieczeństwa) jest częstą decyzją i tematem rozmowy o pracę, zrozumienie różnicy — ich efektów na historię, krytycznej złotej reguły i kiedy używać każdego — jest cenna, praktycznie ważna wiedza na temat Gita, która jest centralna dla utrzymania czystej historii w bezpieczny sposób i powszechnie omawiana różnica, którą każdy programista powinien zrozumieć.