Mitä eroa on rebasella ja mergellä?

Question

Accepted Answer

Sekä **merge** että **rebase** integroivat muutoksia yhdestä haarasta toiseen, mutta ne tekevät sen eri tavalla: merge **säilyttää historian** merge-commitilla, kun taas rebase **kirjoittaa historian uudelleen** luodakseen lineaarisen sekvenssin. Ero ymmärtäminen ja oikea käyttötilanne on tärkeää.

## Merge — säilyttää historian (yhdistää)

```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 — kirjoittaa uudelleen lineaariselle historialle (toistaa)

```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 **siirtää** haaran commitit alkamaan toisesta haarasta, luoden uusia committeja — tuottaen puhtaan, lineaarisen historian.

## Rebasing-säännön kultainen muoto

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

## Milloin käyttää kumpaakin

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

## Miksi se on tärkeää

Rebasen ja mergen eron ymmärtäminen on tärkeää, koska molemmat integroivat muutoksia, mutta niillä on perustavanlaatuisesti erilaiset vaikutukset historiaan, ja oikean valinnan tekeminen (turvallisesti) on merkityksellistä, joten se on arvokas Git-tieto, jota myös yleisesti käsitellään.

Ydin-ero — **merge säilyttää historian** (luoden merge-commitin, joka tallentaa haarat yhdistetyksi, säilyttäen todellisen kehityshistorian) kun taas **rebase kirjoittaa historian uudelleen** (toistamalla committit toiselle haaralle luodakseen puhtaan, lineaarisen sekvenssin ikään kuin työ olisi tehty uusimman koodin päällä) — vaikuttaa siihen, miltä projektin historia näyttää ja kuulostaa.

Kauppa-arvojen ymmärtäminen (merge: tarkka mutta mahdollisesti sotkuinen merge-commiteista; rebase: puhdas ja lineaarinen mutta committien uudelleen kirjoitus) auttaa valitsemaan sen perusteella, arvostutkko oikean historian vai lineaarisen puhtauden.

Kaikista kriittisimmäksi, **rebasing-säännön kultainen muoto** ymmärtäminen — **älä koskaan rebase committeja, jotka on pushittu/jaettu** — on olennaista, koska rebase kirjoittaa committit uudelleen (antamalla niille uudet hashit), joten jaetun historian rebasing eroaa siitä, mitä yhteistyötekijöillä on, aiheuttaen vakavia ristiriitoja ja konflikteja; rebase on turvallista vain paikalliset, pushittamattomille committille.

Tämä turvallisuussääntö on elintärkeä ja yleinen ongelmalähde kun sitä rikotaan.

Ymmärtäminen **milloin käyttää kumpaakin** (merge jaettujen haarojen integrointiin ja historian säilyttämiseen, usein tiimin oletuksena ominaisuuksien yhdistämiseen pull-pyyntöjen kautta; rebase paikallisten committien siivoamiseen ennen jakamista tai feature-haaran pitämiseen lineaarisesti ajan tasalla — vain paikalliset committit) heijastaa terveellistä Git-käytäntöä.

Koska muutosten integroiminen on perustavanlaatuista ja merge-vs-rebase valinta (sen historian ja turvallisuusvaikutuksien kanssa) on usein tehtävä päätös ja haastatteluaihe, ero ymmärtäminen — niiden vaikutukset historiaan, kriittinen kultainen sääntö ja milloin käyttää kumpaakin — on arvokas, käytännön kannalta tärkeä Git-tieto, joka on keskeinen puhtaan historian ylläpitämiselle turvallisesti ja yleinen ero, jonka jokaisen kehittäjän pitäisi ymmärtää.