Merge — mi ez, az egyesítés típusai és működési mechanizmusa

Mi az a Merge?

Merge (egyesítés) — egy alapvető művelet a Git-ben, amely egyesíti a változtatásokat az egyik ágból (source) a másikba (target). Az egyesítés eredményeként a célág megkapja a forráság összes commitját, amelyek még nem voltak benne. A helyzettől függően a Git három különböző módon hajthatja végre a merge-t.

A merge fő értéke a történet megőrzése: a merge commit rögzíti az ágak egyesítésének tényét, tárolja az információt arról, hogy mikor és mely ágak lettek egyesítve. Ez megkönnyíti a változtatások auditálását, a regressziók keresését és a fejlesztés kronológiájának megértését. Nagy projektekben a merge commit a kódintegráció standard módja.

A GitLab Flow adatai szerint a merge commiteket a Git-ben dolgozó csapatok 73%-a használja. Az alternatív megközelítéseket (rebase, squash) a lineáris történetre orientált csapatok részesítik előnyben. A stratégia választása a csapat méretétől, a kiadások gyakoriságától és a projektben elfogadott megállapodásoktól függ.

Mikor van szükség Merge-re

Merge akkor szükséges, amikor a fejlesztő befejezte a munkát egy funkción, és integrálni szeretné azt a develop-ba vagy main-be. Tipikus forgatókönyv: a fejlesztő létrehozott egy funkció ágat a develop-ból, néhány napig dolgozott rajta, és ezalatt új commitek jelentek meg a develop-ban más résztvevőktől. Az egyesítés előtt össze kell kapcsolni a változtatásokat — és erre szolgál a merge.

Merge nélkül lehetetlen közösen dolgozni egy kódon a Git-ben. Minden alkalommal, amikor két fejlesztő egyidejűleg változtatásokat végez ugyanabban a kódbázisban, az ágaik eltérnek. A Merge — az egyetlen módja, hogy ezeket a változtatásokat adatvesztés nélkül visszaegyesítsük.

Egyesítés típusai a Git-ben

A Git három típusú merge-t támogat, mindegyik a saját forgatókönyvére szabva. Az egyesítés típusának kiválasztása befolyásolja a commitok történetét, a visszaállítás kényelmét és a log olvashatóságát.

Fast-forward merge

Fast-forward akkor következik be, amikor a célágnak nem voltak új commitei a forráság létrehozása óta. Ebben az esetben a Git egyszerűen előre mozdítja a célág mutatóját a forráság utolsó commitjára. A történet lineáris marad, merge commit nélkül.

# Fast-forward merge: a develop nem változott a feature létrehozása óta
git checkout develop
git merge feature/new-login

# Eredmény: a develop mutatója a feature végére mozdult
# Nem jött létre merge commit

A Fast-forward a rövid életű ágakhoz kényelmes, ahol a fejlesztő egyedül dolgozott. Ennek a megközelítésnek azonban van hátránya: elvész az információ arról, hogy az ág létezett — minden commit úgy néz ki, mintha közvetlenül a develop-ban készült volna.

Three-way merge

Three-way merge akkor hajtódik végre, amikor mindkét ágnak új commitei vannak az eltérési pont után. A Git létrehoz egy külön merge commitot két szülővel, amely rögzíti az ágak egyesítésének tényét. Ez a megközelítés ajánlott a funkció ágakhoz a csapatfejlesztésben.

# Kényszerített three-way merge a --no-ff zászlóval
git checkout develop
git merge --no-ff feature/new-login

# Merge commit létrehozva alapértelmezett üzenettel
# Saját üzenet beállítható a -m segítségével
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

A --no-ff zászló garantálja a merge commit létrehozását, még akkor is, ha a fast-forward lehetséges. Ez a legjobb gyakorlat az elágazásokkal kapcsolatos információ megőrzésére a projektben.

Squash merge

Squash merge összetömöríti a forráság összes commitját egybe, és alkalmazza a célágra. A funkció története elveszik — egy commit kerül az ágba az összes változtatással. Ez akkor kényelmes, amikor a részletes commitek a funkció ágban nem hordoznak értéket az általános történet számára.

# Squash merge: a feature összes commitja egybe tömörítve
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash piszkozatokhoz, kísérleti ágakhoz és olyan helyzetekhez alkalmas, amikor a történet tisztaságának megőrzése fontos. Hátrány — az eredeti commitekkel való kapcsolat elveszik, ami megnehezíti az egyes változtatások visszaállítását.

Ours és Theirs stratégiák

Ours és Theirs — két speciális merge stratégia a Git-ben. Az Ours teljesen figyelmen kívül hagyja a forráság változtatásait, csak azt tartja meg, ami a célágban van. A Theirs ellenkezőleg, minden konfliktusnál elfogadja a forráság verzióját. Ezek a stratégiák nagy mennyiségű kód egyesítésekor hasznosak, amikor előre ismert, melyik verziónak kell győznie.

Hogyan működik a Merge

A merge mechanizmusa a Git-ben három pont összehasonlításán alapul: a közös ős (merge base), a forráság állapota és a célág állapota. A Git megtalálja a merge base-t — az utolsó commitot, amely mindkét ágban közös — és kiszámítja, milyen változtatások történtek az egyes ágakban az eltérés után.

• 1. lépés — A Git meghatározza a merge base-t: az utolsó commitot, amely mindkét ágban létezik
• 2. lépés — A Git két diffet épít: a merge base-től a source-ig és a merge base-től a target-ig
• 3. lépés — A Git megpróbálja alkalmazni mindkét változtatáskészletet a merge base-re
• 4. lépés — Ha a változtatások nem ütköznek — a merge automatikusan befejeződik
• 5. lépés — Ha konfliktus van — a Git megáll és megoldást kér

A Git háromirányú egyesítési algoritmust használ, amely nemcsak a fájl két összehasonlított verzióját veszi figyelembe, hanem azok közös ősét is. Ennek köszönhetően a Git automatikusan meg tudja oldani azokat a helyzeteket, amikor az egyik ág változtatásai nem érintik a másik módosított részeit — még akkor is, ha mindkét fájl módosult.

A merge algoritmusának működése példán keresztül

Tekintsük a forgatókönyvet: két fejlesztő különböző fájlokon dolgozik ugyanabban a funkció ágban. Az első módosította a LoginActivity.kt-t, a második — a ProfileFragment.kt-t. Amikor egyesítik a változtatásaikat, a Git látja, hogy a változtatások különböző fájlokat érintenek, és automatikusan végrehajtja a merge-t, emberi beavatkozás nélkül.

Ha mindkét fejlesztő módosította a LoginActivity.kt-t, de különböző metódusokban — a Git szintén automatikusan megbirkózik vele, sorról sorra egyesítve a változtatásokat. Konfliktus csak akkor keletkezik, ha mindketten ugyanazokat a sorokat módosították, vagy ha az egyik törölte azt a kódot, amelyet a másik módosított.

Konfliktusok feloldása Merge-nél

Merge konfliktus akkor keletkezik, amikor a Git nem tudja automatikusan egyesíteni a változtatásokat, mert mindkét ág ugyanazokat a sorokat különböző módon módosította. Ebben az esetben a Git megjelöli a konfliktusos részeket a fájlokban, és várja a fejlesztő manuális megoldását.

A konfliktusos részek megjelölésre kerülnek speciális jelölőkkel: a <<<<<<< HEAD a célág kódját mutatja, a ======= — az elválasztót, a >>>>>>> source-branch — a forráság kódját. A fejlesztőnek manuálisan kell kiválasztania, melyik változatot tartsa meg, vagy egyesítenie kell azokat.

# 1. Merge indítása és konfliktus megtekintése
git merge feature/new-login
# Kimenet: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Konfliktusos fájlok listájának megtekintése
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Konfliktus feloldása: fájl szerkesztése, jelölők eltávolítása
# 4. Feloldott fájl hozzáadása és merge befejezése
git add src/ui/login/LoginActivity.kt
git merge --continue
# vagy: git commit (--continue nélkül)

A konfliktusok feloldásához eszközök állnak rendelkezésre: a git mergetool megnyit egy vizuális mergert (Meld, Beyond Compare, VS Code). Sok fejlesztő szívesebben oldja meg a konfliktusokat az IDE-ben — az IntelliJ IDEA és az Android Studio beépített eszközt biztosít hárompaneles összehasonlítással, ami jelentősen leegyszerűsíti ezt a folyamatot.

Tippek a konfliktusok feloldásához: mindig értse meg, mit csinál a konfliktus mindkét oldala, ne törölje mások kódját anélkül, hogy megértené annak logikáját, és ha a konfliktus túl bonyolult — vonja be mindkét ág szerzőjét a közös megoldásba.

Merge vs Rebase: mikor mit válasszunk

A Merge és Rebase közötti választás — az egyik leggyakoribb architekturális döntés a Git-ben. Mindkét megközelítés egyesíti a változtatásokat, de különböző módon: a merge megőrzi az elágazások történetét, a rebase átírja a történetet, lineárissá téve azt.

• Merge — megőrzi a kontextust: látható, mikor és melyik ágból történt az egyesítés. Jobb a nyilvános ágakhoz (develop, main) és a csapatmunkához
• Rebase — tiszta lineáris történetet hoz létre felesleges merge commitek nélkül. Jobb a személyes funkció ágakhoz a review-ra küldés előtt
• Szabály: soha ne végezzen rebase-t olyan nyilvános ágakon, amelyeket más fejlesztők használnak

Számos csapat hibrid megközelítést használ: rebase-t a funkció ág naprakész állapotba hozásához a develop-hoz képest (git rebase develop), majd merge-t a --no-ff zászlóval az egyesítés rögzítéséhez. Ez tiszta történetet ad a funkción belül és informatív egyesítési pontokat a develop szintjén.