Merge — ce este, tipuri de îmbinare și mecanism de funcționare

Ce este Merge?

Merge (îmbinare) — este o operațiune fundamentală în Git care combină modificările dintr-o ramură (source) în alta (target). În urma îmbinării, ramura țintă primește toate commiturile din ramura sursă care nu erau încă prezente în ea. În funcție de situație, Git poate executa merge în trei moduri diferite.

Valoarea principală a merge-ului este păstrarea istoriei: merge commit înregistrează faptul combinării ramurilor, păstrează informația despre când și care ramuri au fost îmbinate. Acest lucru facilitează auditul modificărilor, căutarea regresiilor și înțelegerea cronologiei dezvoltării. În proiecte mari, merge commit este modul standard de integrare a codului.

Conform datelor GitLab Flow, merge commiturile sunt utilizate în 73% din echipele care lucrează cu Git. Abordările alternative (rebase, squash) sunt preferate de echipele orientate spre istoria liniară. Alegerea strategiei depinde de mărimea echipei, frecvența lansărilor și convențiile adoptate în proiect.

Când apare Merge

Merge este necesar când dezvoltatorul a terminat lucrul la o funcționalitate și dorește să o integreze în develop sau main. Scenariu tipic: dezvoltatorul a creat o ramură de funcționalitate din develop, a lucrat câteva zile, iar în acest timp în develop au apărut commituri noi de la alți participanți. Înainte de îmbinare trebuie combinate modificările — și pentru aceasta se folosește merge.

Fără merge nu se poate lucra în echipă la același cod în Git. De fiecare dată când doi dezvoltatori introduc simultan modificări în aceeași bază de cod, ramurile lor diverg. Merge — este singura modalitate de a reuni aceste modificări fără pierdere de date.

Tipuri de îmbinare în Git

Git suportă trei tipuri de merge, fiecare destinat propriului scenariu. Alegerea tipului de îmbinare influențează istoria commiturilor, confortul revenirii și lizibilitatea logului.

Fast-forward merge

Fast-forward apare când ramura țintă nu a avut commituri noi de la crearea ramurii sursă. În acest caz, Git pur și simplu mută indicatorul ramurii țintă înainte, la ultimul commit al ramurii sursă. Istoria rămâne liniară, fără merge commit.

# Fast-forward merge: develop nu s-a modificat de la crearea feature
git checkout develop
git merge feature/new-login

# Rezultat: indicatorul develop s-a mutat la sfârșitul lui feature
# Nu s-a creat niciun merge commit

Fast-forward este convenabil pentru ramurile de scurtă durată, unde dezvoltatorul a lucrat singur. Dar această abordare are un dezavantaj: se pierde informația că ramura a existat — toate commiturile par a fi făcute direct în develop.

Three-way merge

Three-way merge se execută când ambele ramuri au commituri noi după punctul de divergență. Git creează un merge commit separat cu doi părinți, care înregistrează faptul combinării ramurilor. Această abordare este recomandată pentru ramurile de funcționalitate în dezvoltarea în echipă.

# Three-way merge forțat cu flagul --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Merge commit creat cu mesajul implicit
# Se poate seta propriul mesaj prin -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Flagul --no-ff garantează crearea unui merge commit, chiar dacă fast-forward este posibil. Aceasta este cea mai bună practică pentru păstrarea informației despre ramificare în proiect.

Squash merge

Squash merge comprimă toate commiturile ramurii sursă într-unul singur și îl aplică ramurii țintă. Istoria funcționalității se pierde — în ramură ajunge un singur commit cu toate modificările. Este convenabil când commiturile detaliate din ramura de funcționalitate nu aduc valoare istoriei generale.

# Squash merge: toate commiturile feature au fost comprimate într-unul singur
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash este potrivit pentru ciorne, ramuri experimentale și situații când este importantă păstrarea curățeniei istoriei. Minus — se pierde legătura cu commiturile originale, ceea ce complică revenirea modificărilor individuale.

Strategiile Ours și Theirs

Ours și Theirs — două strategii speciale de merge în Git. Ours ignoră complet modificările din ramura sursă, păstrând doar ce este în ramura țintă. Theirs, dimpotrivă, acceptă versiunea ramurii sursă la orice conflict. Aceste strategii sunt utile la îmbinarea unor volume mari de cod, când se știe dinainte care versiune trebuie să câștige.

Cum funcționează Merge

Mecanismul merge în Git se bazează pe compararea a trei puncte: strămoșul comun (merge base), starea ramurii sursă și starea ramurii țintă. Git găsește merge base — ultimul commit comun pentru ambele ramuri — și calculează ce modificări au avut loc în fiecare ramură după divergență.

• Pasul 1 — Git determină merge base: ultimul commit care există în ambele ramuri
• Pasul 2 — Git construiește două diffuri: de la merge base la source și de la merge base la target
• Pasul 3 — Git încearcă să aplice ambele seturi de modificări la merge base
• Pasul 4 — Dacă modificările nu intră în conflict — merge se finalizează automat
• Pasul 5 — Dacă există conflict — Git se oprește și solicită rezolvarea

Git folosește algoritmul trilateral de îmbinare, care ia în considerare nu doar cele două versiuni comparate ale fișierului, ci și strămoșul lor comun. Datorită acestui fapt, Git poate rezolva automat situațiile în care modificările dintr-o ramură nu afectează părțile modificate ale celeilalte — chiar dacă ambele fișiere au fost modificate.

Algoritmul de funcționare a merge-ului pe un exemplu

Să considerăm scenariul: doi dezvoltatori lucrează la fișiere diferite în aceeași ramură de funcționalitate. Primul a modificat LoginActivity.kt, al doilea — ProfileFragment.kt. Când își îmbină modificările, Git vede că modificările au afectat fișiere diferite și execută merge automat, fără intervenția umană.

Dacă ambii dezvoltatori au modificat LoginActivity.kt, dar în metode diferite — Git se va descurca și el automat, combinând modificările rând cu rând. Conflictul apare doar dacă ambii au modificat aceleași rânduri sau dacă unul a șters codul pe care celălalt l-a modificat.

Rezolvarea conflictelor la Merge

Conflictul de merge apare când Git nu poate combina automat modificările, deoarece ambele ramuri au modificat aceleași rânduri în mod diferit. În acest caz, Git marchează porțiunile conflictuale în fișiere și așteaptă rezolvarea manuală de către dezvoltator.

Porțiunile conflictuale sunt marcate cu markeri speciali: <<<<<<< HEAD arată codul din ramura țintă, ======= — separatorul, >>>>>>> source-branch — codul din ramura sursă. Dezvoltatorul trebuie să aleagă manual ce variantă să păstreze sau să le combine.

# 1. Porniți merge și vedeți conflictul
git merge feature/new-login
# Rezultat: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Vizualizați lista fișierelor cu conflicte
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Rezolvați conflictul: editați fișierul, eliminați markerii
# 4. Adăugați fișierul rezolvat și finalizați merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# sau: git commit (fără --continue)

Pentru rezolvarea conflictelor există instrumente: git mergetool deschide un merger vizual (Meld, Beyond Compare, VS Code). Mulți dezvoltatori preferă să rezolve conflictele în IDE — IntelliJ IDEA și Android Studio oferă un instrument încorporat cu comparație pe trei panouri, care simplifică semnificativ acest proces.

Sfaturi pentru rezolvarea conflictelor: înțelegeți întotdeauna ce face fiecare parte a conflictului, nu ștergeți codul altcuiva fără a înțelege logica lui, iar dacă conflictul este prea complex — implicați autorul ambelor ramuri la rezolvarea comună.

Merge vs Rebase: când să alegi ce

Alegerea între Merge și Rebase — una dintre cele mai frecvente decizii arhitecturale în Git. Ambele abordări combină modificările, dar o fac diferit: merge păstrează istoria ramificării, rebase rescrie istoria, făcând-o liniară.

• Merge — păstrează contextul: se vede când și de la care ramură s-a făcut îmbinarea. Mai bun pentru ramurile publice (develop, main) și lucrul în echipă
• Rebase — creează o istorie liniară curată fără merge commituri inutile. Mai bun pentru ramurile personale de funcționalitate înainte de trimiterea la review
• Regula: nu faceți niciodată rebase pe ramurile publice pe care le folosesc alți dezvoltatori

Multe echipe folosesc abordarea hibridă: rebase pentru a aduce ramura de funcționalitate la starea actuală a develop (git rebase develop), apoi merge cu flagul --no-ff pentru fixarea îmbinării. Aceasta oferă o istorie curată în interiorul funcționalității și puncte de îmbinare informative la nivelul develop.