Koks yra skirtumas tarp rebase ir merge?

Question

Accepted Answer

Tiek **merge**, tiek **rebase** integruoja pakeitimus iš vienos šakos į kitą, bet jie tai daro skirtingai: merge **išsaugo istoriją** su merge commit, o rebase **perrašo istoriją**, kad būtų sukurta tiesinė seka. Svarbu suprasti skirtumą ir kada naudoti kiekvieną.

## Merge — išsaugo istoriją (sujungia)

```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 — perrašo, kad būtų tiesinė istorija (pakartoja)

```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 **perkeliaš** jūsų šakos commit'us pradėti nuo kitos šakos galo, sukurdamas naujus commit'us — gamindamas švarias, tiesinę istoriją.

## Pagrindinis rebase taisymas

```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 naudoti kiekvieną

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

## Kodėl tai svarbu

Suprasti skirtumą tarp rebase ir merge yra svarbu, nes abu integruoja pakeitimus, bet su fundamentaliai skirtingais poveikiais istorijai, o pasirinkimas teisingai (ir saugiai) yra svarbus, todėl tai vertinga Git žinija, kurią taip pat dažnai aptariama.

Pagrindinė diskreticija — **merge išsaugo istoriją** (sukurdamas merge commit'ą, kuris registruoja sujungtas šakas, išsaugant tikrąją plėtros istoriją), tuo tarpu **rebase perrašo istoriją** (pakartojant commit'us į kitos šakos galą, kad būtų sukurta švari, tiesinė seka, tarsi darbas būtų atliktas su naujausiu kodu) — paveikia tai, kaip atrodo projekto istorija ir kaip ji skaitoma.

Supratimas apie kompromisus (merge: tikslus, bet potencialiai sumaišytas su merge commit'ais; rebase: švarus ir tiesinis, bet perrašyti commit'ai) padeda pasirinkti remiantis tuo, ar jūs vertinate tikrąją istoriją, ar tiesinį švarbumą.

Svarbiausias aspektas yra supratimas apie **pagrindinį rebase taisymą** — **niekada nedaryk rebase į commit'us, kurie buvo push'inti/pasidalinti** — nes rebase perrašo commit'us (suteikdamas jiems naujus hash'us), todėl rebase pasidalintai istoriai sukelia divergenciją nuo to, ką turi bendradarbiai, sukeliant seriozus painiavą ir konfliktus; rebase yra saugus tik lokalių, nepush'intų commit'ų atveju.

Šis saugos taisymas yra gyvybiškai svarbus ir dažnas problemų šaltinis, kai jis pažeidžiamas.

Supratimas apie **kada naudoti kiekvieną** (merge integruojant pasidalintas šakas ir išsaugant istoriją, dažnai komandos numatytasis variantas merge'inant funkcijas per pull request'us; rebase valant vietinius commit'us prieš pasidalinimą arba laikant funkcijos šaką tiesiškai atnaujintą — tik iš vietinių commit'ų) atspindi gražią Git praktiką.

Kadangi pakeitimų integravimas yra fundamentalus, o merge vs rebase pasirinkimas (su jo istorijos ir saugos implikacijomis) yra dažna sprendimo priemone ir interviu tema, supratimas apie skirtumą — jų poveikį istorijai, kritinį pagrindinį taisymą ir kada naudoti kiekvieną — yra vertinga, praktiškai svarbi Git žinija, kuri yra pagrindinė švarios istorijos išsaugojimui saugiai ir dažnai aptariamai diskretijai, kurią kiekvienas programuotojas turėtų suprasti.