Összeolvasztás (merge) — mi ez, hogyan működik a merge és az egyesítési stratégiák

Mi a merge Git-ben

Merge — ez a git merge parancs, amely egyesíti a megadott ág változásait az aktuális ágba. A Git megtalálja a közös őst (közös alap kommit), kiszámítja az egyes ágak diff-jét az őshöz képest, és létrehoz egy merge-kommitot, amely az egyesített változások halmazát tartalmazza. Eredmény — a célág kiegészül az egyesített ág összes változásával.

Szintaxis: a célágban (pl. main) tartózkodva hajtsd végre a git merge feature parancsot. A Git automatikusan létrehoz egy merge-kommitot, ha nincsenek konfliktusok. A merge-kommit alapértelmezett üzenetében ez szerepel: „Merge branch ’feature’ into main“. Az üzenet a -m flag segítségével módosítható vagy a megnyitott szerkesztőben szerkeszthető.

A merge egy nem romboló művelet. A rebase-szel ellentétben a merge nem nyúl a meglévő kommitokhoz: azok ugyanazokkal a hashekkel, szerzőkkel és dátumokkal maradnak. Ez teszi a merge-t az egyetlen biztonságos egyesítési móddá az olyan ágak számára, amelyeken egyszerre több fejlesztő dolgozik. Ha valami rosszul sül el, a merge a git merge --abort paranccsal visszavonható.

# Válts célágra
git checkout main

# Feature ág egyesítése
git merge feature

# Eredmény — merge-kommit két szülővel
git log --oneline --graph

# Egyesítés egyéni üzenettel
git merge feature -m "feat: integrate authentication module"

Merge típusok: regular, squash, fast-forward

A Git három egyesítési módot támogat, amelyeket a kívánt eredménytől függően választanak ki. A regular merge (alapértelmezett) merge-kommitot hoz létre. A squash merge a feature-ág összes kommitját egyesíti egyetlen kommittá. A fast-forward — előre mozgatja az ág mutatóját kommit létrehozása nélkül, ha lehetséges. A mód kiválasztása a csapat workflow-jától és a történeti szabályoktól függ.

Regular merge (--no-ff) — merge-kommitot hoz létre akkor is, ha az egyesítés fast-forwardként is végrehajtható. A main ág számára ajánlott: a merge-kommit explicit módon jelöli a funkció integrációjának pillanatát, és lehetővé teszi a feature-ág összes változásának egyszerű visszavonását egyetlen revert merge-kommit segítségével. A GitHub alapértelmezés szerint ezt a módot használja a PR-ek Merge gombon keresztüli egyesítésekor.

Squash merge (--squash) — összegyűjti a feature-ág összes kommitját egyetlen kommittá a célágban. Hasznos, ha a feature-ág kezdetleges története nem kerülhet a main-be. Hátrány: az eredeti kommitokkal való kapcsolat megszűnik — nem látható, hogy a funkció lépésről lépésre hogyan fejlődött. A GitHub ezt a módot használja a „Squash and merge“ kiválasztásakor a PR-ben.

Fast-forward (--ff) — ha a célágban nincsenek új kommitok a feature elágazása után, a Git egyszerűen előre mozgatja a mutatót, merge-kommit létrehozása nélkül. A történet lineáris marad. A --no-ff flag kényszeríti a merge-kommit létrehozását, a --ff-only hibaüzenettel végződik, ha a fast-forward nem lehetséges.

# Merge-kommit kényszerítése (ajánlott main-hez)
git merge --no-ff feature

# Squash merge — az összes kommit egyetlen kommittá
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward csak ha lehetséges
git merge --ff-only feature

# Konfliktusos merge megszakítása
git merge --abort

Git egyesítési stratégiák

Az egyesítési stratégiák meghatározzák azt az algoritmust, amelyet a Git a változások kombinálásához használ. Minden stratégia különböző forgatókönyvekhez alkalmas. A Git automatikusan kiválasztja a megfelelő stratégiát, de a fejlesztő explicit módon megadhatja azt a --strategy flag segítségével. A stratégiák megértése segít előre jelezni a Git viselkedését összetett egyesítéseknél.

Recursive — az alapértelmezett stratégia két ág egyesítésére. A Git megtalálja a közös őst, kiszámítja a változásokat minden ágban, és egyesíti azokat. Ha a közös ős megtalálható, a recursive helyesen kezeli a fájlok átnevezését és új fájlok hozzáadását. Konfliktusok esetén a recursive további opciókat használhat: ours (automatikusan a mi verziót választja) és theirs (az ő verziót választja).

Octopus — kettőnél több ág egyidejű egyesítéséhez: git merge feature1 feature2 feature3. Az Octopus nem támogatja a konfliktusmegoldást — minden konfliktust meg kell oldani a parancs meghívása előtt. Ritkán használatos, főként több független ág összekapcsolására, amelyek garantáltan nem ütköznek (pl. különböző modulok).

Ours — egy különleges stratégia, amely teljesen figyelmen kívül hagyja az egyesített ág változásait, és megtartja a célág aktuális tartalmát. A merge-kommit létrejön, de a tartalom változatlan marad. Hasznos, ha a történetben rögzíteni kell az egyesítés tényét, de gyakorlatilag el kell utasítani a másik ág összes változását.

Merge-konfliktusok megoldása

Merge-konfliktus akkor keletkezik, amikor egy fájl ugyanazokat a sorait mindkét ágban eltérően módosították. A Git nem tudja automatikusan meghatározni, melyik verzió a helyes, és felfüggeszti a merge-t. Konfliktus keletkezhet akkor is, ha egy fájlt az egyik ágban átneveznek, a másikban pedig módosítanak, vagy ha ugyanazt a fájlt egyszerre törlik és módosítják.

A megoldás folyamata: A Git megjelöli a konfliktusos fájlokat markerekkel. A fájlban megjelennek a <<<<<<< HEAD (a mi verziónk), ======= (elválasztó) és >>>>>>> feature (az ő verziónk) részek. A fejlesztő kézzel szerkeszti a konfliktusos részt, kiválasztja a szükséges sorokat mindkét verzióból, eltávolítja a markereket, elmenti a fájlt, és hozzáadja az indexhez a git add paranccsal.

A konfliktusok vizuális megoldásához a Git támogatja a mergetool — egy külső összehasonlító eszközt. Népszerű mergetool eszközök: Meld, KDiff3, Beyond Compare, VS Code (beépített konfliktusszerkesztő). A Mergetool három panelt jelenít meg: a mi verzió, az ő verzió és az eredmény. A fejlesztő vizuálisan választja ki a végső fájlba beillesztendő kódblokkokat.

# Merge indítása és konfliktus érzékelése
git merge feature
# KONFLIKTUS (tartalom): Merge konfliktus a src/main.swift fájlban

# Konfliktusos fájlok ellenőrzése
git status

# Vizuális mergetool megnyitása
git mergetool

# Megoldás után — hozzáadás és commit
git add src/main.swift
git commit

# Merge megszakítása
git merge --abort

Mikor válasszuk a merge-t a rebase helyett

A merge előnyben részesítendő a rebase-szel szemben néhány kulcsfontosságú helyzetben. Első: nyilvános, más fejlesztők számára hozzáférhető ágakkal való munka során. A merge nem írja felül a történetet, és a kollégák biztonságosan szinkronizálhatnak. A rebase egy nyilvános ágban eltérő történetet és konfliktusokat hoz létre mindazok számára, akik már megkapták a régi kommitokat.

Második helyzet: a feature-ág befejezésekor. A legtöbb csapat a merge-t (a --no-ff flaggel) részesíti előnyben a main-be a funkció integráció pillanatának rögzítéséhez. Ez leegyszerűsíti a történetben való navigációt, és lehetővé teszi a teljes funkció egyszerű visszavonását egyetlen git revert merge-kommit segítségével. A GitHub Flow alapértelmezés szerint három merge opciót kínál: egyszerű merge, squash merge és rebase merge.

Harmadik helyzet: pull request használata esetén, amely átesett a review-n. A GitHub és a GitLab merge gombot kínál különböző opciókkal. Merge (Create a merge commit) — teljes történet merge-kommittel. Squash and merge — tiszta történet fejlesztési részletek nélkül. Rebase and merge — lineáris történet merge-kommit nélkül, de a kommitok felülírásával. A választás a csapat szabályaitól függ.

• Nyilvános ágak (main, develop) — csak merge, soha ne rebase.
• PR befejezése — merge --no-ff flaggel az integráció pillanatának rögzítéséhez.
• Mások kommitjaival rendelkező ágak — a merge nem írja felül mások munkáját.
• Kiadás előtt — a merge biztonságosabb, mivel kevesebb kockázattal jár.
• Közös ág — ha többen dolgoznak az ágon, a merge kötelező.

Legjobb gyakorlatok az ágak egyesítéséhez

Első szabály: mindig a célág aktuális verzióján legyél a merge előtt. Végre git checkout main && git pull parancsot, mielőtt egyesíted a funkciót. Ez minimalizálja a konfliktusokat, és garantálja, hogy a merge-kommit tartalmazni fogja az összes aktuális változást. Ha a célág messze előrehaladt, először hajtsd végre a git merge main parancsot a feature-ágon belül a konfliktusok annak kontextusában történő megoldásához.

Második szabály: teszteld a kódot merge után. A merge megváltoztathatja a viselkedést, még akkor is, ha nem voltak konfliktusok. A CI/CD pipeline-nak le kell futtatnia a teszteket a merge-kommiton, mielőtt éles környezetbe kerülne. Egyes csapatok merge gates — kötelező ellenőrzéseket használnak, amelyek blokkolják a merge-t, amíg azokon át nem mennek.

Harmadik szabály: dokumentáld a merge-kommitokat. A standard „Merge branch ’feature’ into main“ üzenet kevéssé hasznos. Ajánlott hozzáadni a leírást arról, hogy mi lett egyesítve: „Merge authentication module: login, registration, password recovery“. Ez leegyszerűsíti a történet elemzését és a regressziók keresését. Nagy projektekben a merge-kommitok automatikusan generálódnak a PR nevéből.

• Aktualitás — merge előtt győződj meg róla, hogy a célág frissítve van (git pull).
• Tesztelés — a CI/CD futtasson teszteket az eredményül kapott merge-kommiton.
• Leíró üzenetek — add meg a merge-kommitban, hogy melyik funkció lett egyesítve.
• Gyakoriság — egyesítsd a feature-ágakat a lehető legkorábban és leggyakrabban (maximum egy hét).
• Visszavonás — a git revert merge-kommit a teljes funkciót visszavonja.