Branch-ek összeolvasztása — mi ez, az összeolvasztás módjai és konfliktusok feloldása

Mi az a merge a Git-ben

A merge a Git-ben — két vagy több fejlesztési történet egyetlen történetbe történő egyesítésének művelete. Amikor egy fejlesztő összeolvaszt egy branch-et, a Git automatikusan megtalálja a közös őst (base commit), és létrehoz egy új merge commit-et, amely mindkét branch változtatásait tartalmazza. Three-way merge — a szabványos algoritmus, amely három állapotot hasonlít össze: a közös őst, az első branch-et és a második branch-et.

A merge folyamata a git merge paranccsal kezdődik. A Git meghatározza a branch-ek elágazási pontját, és szekvenciálisan alkalmazza a változtatásokat a forrásbranch-ből a célbranch-ra. Ha a változtatások nem ütköznek, a Git a beállításoktól függően fast-forward-t hajt végre, vagy merge commit-et hoz létre. Fast-forward — az a forgatókönyv, amikor a célbranch egyszerűen a forrásbranch commit-jaira mozdul el.

# Válts a célbranch-ra és egyesíts
git checkout main
git merge feature/payment-module

# Egyesíts explicit no-fast-forward használatával
git merge --no-ff feature/payment-module

# Szakítsd meg az egyesítést, ha a konfliktusok túl bonyolultak
git merge --abort

A --no-ff (no fast-forward) zászló kényszeríti a merge commit létrehozását akkor is, ha a fast-forward lehetséges. Ez megőrzi az információt arról, hogy a változtatások külön branch-ben készültek. Sok csapat pontosan ezt a megközelítést részesíti előnyben a történet elágazásának explicit megőrzéséhez.

Branch-ek összeolvasztásának módjai

A Git-ben három fő stratégiája létezik a branch-ek összeolvasztásának, mindegyik egy adott forgatókönyvhöz illik. A stratégia kiválasztása a csapat kultúrájától és a projekt történetének tisztaságára vonatkozó követelményektől függ.

A Standard merge két szülővel rendelkező merge commit-et hoz létre. A teljes történet megmarad, de az elágazási gráf bonyolultabbá válik. Squash merge a feature branch összes commit-ját egyetlen commit-té egyesíti, és alkalmazza a célbranch-ra — a történet lineárissá és tisztává válik, de az információk a köztes szakaszokról elvesznek.

A Rebase, bár nem teljes értékű merge, ugyanazt az eredményt éri el — az egyik branch változtatásai átkerülnek a másikra. A különbség az, hogy a történet átíródik: a feature branch commit-jai újra létrejönnek a célbranch utolsó commit-jának tetején. Ez tökéletesen lineáris történetet ad, de force push-t igényel a küldéskor.

Hogyan oldjuk fel a konfliktusokat merge-kor

Konfliktus merge-kor akkor keletkezik, ha két branch-ben ugyanazok a fájlsorok változtak. A Git nem tudja automatikusan meghatározni, melyik verziót tartsa meg, és a fejlesztő beavatkozását igényli. A konfliktusok speciális markerekként jelennek meg a fájlokban: <<<<<<<, =======, >>>>>>>.

A konfliktusfeloldás folyamata több lépésből áll. Először a fejlesztő megnyitja a konfliktusos fájlt, és kézzel kiválasztja a szükséges változtatásokat. Fontos, hogy ne csak az egyik verziót válasszuk ki, hanem megértsük mindkét változtatás logikáját, és helyes döntést hozzunk. A fájl szerkesztése után a konfliktusmarkerek eltávolításra kerülnek, és a változtatások a git add segítségével a staging területre kerülnek.

# Konfliktusos fájlok listájának megtekintése
git status

# Mergetool indítása (pl. VS Code, IntelliJ)
git mergetool

# Az összes konfliktus feloldása után
git add .
git merge --continue

# Vagy teljesen szakítsd meg az egyesítést
git merge --abort

A vizuális merge eszközök használata jelentősen felgyorsítja a konfliktusok feloldását. A VS Code, az IntelliJ IDEA és a GitKraken hárompaneles felületet biztosít: aktuális branch, bejövő branch és eredmény. A git mergetool eszköz automatikusan megnyitja a konfigurált szerkesztőt minden konfliktusos fájlhoz.

A legjobb módja a bonyolult konfliktusok elkerülésének a feature branch rendszeres szinkronizálása a főággal. Ha a fejlesztő naponta egyszer összeolvasztja a main-t a saját branch-ével, a konfliktusok kicsik és könnyen feloldhatók lesznek. A változtatások egy hét alatti felhalmozódása bonyolult konfliktusokat garantál magas hibakockázattal.

Mikor használjunk rebase-t a merge helyett

A Rebase és a merge — két módja a változtatások kombinálásának, és a köztük való választás gyakran vitákat okoz a csapatokban. A Rebase átviszi a commit-okat az egyik branch-ből a másikba, átírva a történetet. A Merge létrehoz egy új merge commit-et, megőrizve az elágazási történetet. Mindkét megközelítésnek megvannak az előnyei és korlátai.

A Rebase akkor megfelelő, ha egy fejlesztő a saját helyi feature branch-én dolgozik, és tiszta lineáris történetet szeretne kapni a Pull Request létrehozása előtt. Rebase után az összes commit szekvenciálisan rendeződik, felesleges merge commit-ek nélkül. Azonban a Rebase force push-t igényel, és nem alkalmazható olyan branch-eken, amelyeken többen dolgoznak egyszerre.

• Rebase — személyes feature branch-ekhez, ahol tiszta történetre van szükség
• Merge — közös branch-ekhez és az egyesítés pillanatának rögzítéséhez
• Squash — amikor a feature branch sok apró munka commit-ot tartalmaz

A Git aranyszabálya: ne használj rebase-t olyan commit-okon, amelyeket már elküldtek a megosztott repository-ba. Ez garantálja, hogy a történet a közös branch-ben változatlan marad, és a többi fejlesztő nem találkozik duplikált vagy elvesztett commit-okkal. A feature branch főágba történő integrálásához használj merge-t Pull Requesten keresztül.

Legjobb gyakorlatok branch-ek összeolvasztásához

A helyes merge folyamat — a stabil fejlesztés alapja. A modern csapatmunkában a merge nem konzolon keresztül történik, hanem Pull Request-en keresztül GitHub-on vagy Merge Request-en keresztül GitLab-ban. A PR átesik code review-n, automatikus CI-ellenőrzéseken, és csak ezután kerül be a főágba.

Első gyakorlat — csak az összes ellenőrzés sikeres teljesítése után merge-elj. A CI pipeline-nak össze kell építenie a projektet, futtatnia kell a teszteket, és ellenőriznie kell a kód minőségét. Ha akár egy ellenőrzés sem sikerül, a merge blokkolva van. A modern platformok (GitHub, GitLab) beépített védelemmel rendelkeznek: a branch protection rules automatikusan blokkolja a merge-t CI-hiba esetén.

Második gyakorlat — soha ne merge-elj hibás kódot. Merge előtt a fejlesztőnek meg kell győződnie arról, hogy a változtatásai nem törik meg a build-et, és nem regresszálják a meglévő funkcionalitást. Erre szolgálnak az automatikus tesztek és a code review.

Harmadik gyakorlat — tisztítsd meg a feature branch-eket merge után. A már összeolvasztott branch-et törölni kell. Ez megakadályozza a zavart és a repository eltömődését. A GitHub automatikusan felajánlja a branch törlését a PR merge-e után, és a repository beállításai konfigurálhatók automatikus törlésre.