Îmbinarea ramurilor — ce este, metode de îmbinare și rezolvarea conflictelor

Ce este merge-ul în Git

Merge-ul în Git — este operația de combinare a două sau mai multe istorii de dezvoltare într-una singură. Când un dezvoltator îmbină o ramură, Git găsește automat strămoșul comun (base commit) și creează un commit de îmbinare nou care include modificările din ambele ramuri. Three-way merge — algoritmul standard care compară trei stări: strămoșul comun, prima ramură și a doua ramură.

Procesul de merge începe cu comanda git merge. Git determină punctul de divergență al ramurilor și aplică secvențial modificările din ramura sursă peste ramura țintă. Dacă modificările nu intră în conflict, Git execută fast-forward sau creează un merge commit în funcție de setări. Fast-forward — scenariul în care ramura țintă este pur și simplu mutată pe commit-urile ramurii sursă.

# Comută pe ramura țintă și îmbină
git checkout main
git merge feature/payment-module

# Îmbină cu no-fast-forward explicit
git merge --no-ff feature/payment-module

# Anulează îmbinarea dacă conflictele sunt prea complexe
git merge --abort

Flag-ul --no-ff (no fast-forward) forțează crearea unui merge commit chiar și atunci când fast-forward este posibil. Aceasta păstrează informația că modificările au fost făcute într-o ramură separată. Multe echipe preferă această abordare pentru a păstra ramificarea istoriei în formă explicită.

Metode de îmbinare a ramurilor

În Git există trei strategii principale de îmbinare a ramurilor, fiecare potrivită pentru un scenariu specific. Alegerea strategiei depinde de cultura echipei și de cerințele privind curățenia istoriei proiectului.

Standard merge creează un merge commit cu doi părinți. Istoria completă este păstrată, dar graful de ramificare devine mai complex. Squash merge combină toate commit-urile ramurii feature într-unul singur și îl aplică peste ramura țintă — istoria devine liniară și curată, dar se pierde informația despre etapele intermediare.

Rebase, deși nu este un merge propriu-zis, atinge același rezultat — modificările dintr-o ramură sunt transferate peste alta. Diferența constă în rescrierea istoriei: commit-urile ramurii feature sunt recreate deasupra ultimului commit al ramurii țintă. Aceasta oferă o istorie perfect liniară, dar necesită force push la trimitere.

Cum să rezolvăm conflictele la merge

Conflictul la merge apare când în două ramuri sunt modificate aceleași linii ale unui fișier. Git nu poate determina automat ce variantă să păstreze și necesită intervenția dezvoltatorului. Conflictele sunt afișate în fișiere sub formă de markeri speciali: <<<<<<<, =======, >>>>>>>.

Procesul de rezolvare a conflictului include mai mulți pași. Mai întâi, dezvoltatorul deschide fișierul cu conflict și selectează manual modificările necesare. Este important să nu alegi doar una dintre versiuni, ci să înțelegi logica ambelor modificări și să iei o decizie corectă. După editarea fișierului, markerii de conflict sunt eliminați, iar modificările sunt adăugate în staging area prin git add.

# Vezi lista fișierelor cu conflicte
git status

# Pornește mergetool (de ex., VS Code, IntelliJ)
git mergetool

# După rezolvarea tuturor conflictelor
git add .
git merge --continue

# Sau anulează îmbinarea complet
git merge --abort

Utilizarea instrumentelor vizuale de merge accelerează semnificativ rezolvarea conflictelor. VS Code, IntelliJ IDEA și GitKraken oferă interfețe cu trei panouri: ramura curentă, ramura de intrare și rezultatul. Instrumentul git mergetool deschide automat editorul configurat pentru fiecare fișier cu conflict.

Cea mai bună modalitate de a evita conflictele complexe este sincronizarea regulată a ramurii feature cu ramura principală. Dacă dezvoltatorul îmbină main în ramura sa o dată pe zi, conflictele vor fi mici și ușor de rezolvat. Acumularea modificărilor timp de o săptămână garantează conflicte complexe cu risc ridicat de erori.

Când să folosim rebase în loc de merge

Rebase și merge — două moduri de a combina modificări, iar alegerea între ele provoacă adesea dezbateri în echipe. Rebase mută commit-urile dintr-o ramură peste alta, rescriind istoria. Merge creează un nou commit de îmbinare, păstrând istoria ramificării. Fiecare abordare are avantajele și limitările sale.

Rebase este potrivit când un dezvoltator lucrează în propria ramură feature locală și dorește o istorie liniară curată înainte de a crea un Pull Request. După rebase, toate commit-urile se aliniază secvențial, fără merge commit-uri inutile. Totuși, rebase necesită force push și nu se aplică ramurilor pe care lucrează mai multe persoane simultan.

• Rebase — pentru ramuri feature personale, unde este necesară o istorie curată
• Merge — pentru ramuri comune și fixarea momentului îmbinării
• Squash — când ramura feature conține multe commit-uri mici de lucru

Regula de aur a Git: nu folosi rebase pe commit-uri care au fost deja trimise în depozitul comun. Aceasta garantează că istoria în ramura comună rămâne neschimbată, iar alți dezvoltatori nu vor întâlni commit-uri duplicate sau pierdute. Pentru integrarea ramurii feature în ramura principală, folosește merge prin Pull Request.

Cele mai bune practici de îmbinare a ramurilor

Procesul corect de merge — baza dezvoltării stabile. În munca de echipă modernă, merge-ul se execută nu prin consolă, ci prin Pull Request pe GitHub sau Merge Request în GitLab. PR trece prin code review, verificări automate CI și abia apoi este îmbinat în ramura principală.

Prima practică — îmbină doar după trecerea tuturor verificărilor. CI pipeline trebuie să construiască proiectul, să ruleze testele și să verifice calitatea codului. Dacă măcar o verificare nu a trecut, merge-ul este blocat. Platformele moderne (GitHub, GitLab) au protecție încorporată: branch protection rules blochează automat merge-ul la căderea CI.

A doua practică — nu îmbina niciodată cod stricat. Înainte de merge, dezvoltatorul trebuie să se asigure că modificările sale nu strică build-ul și nu regresează funcționalitatea existentă. Pentru aceasta există teste automate și code review.

A treia practică — curăță ramurile feature după merge. Ramura care a fost deja îmbinată trebuie ștearsă. Aceasta previne confuzia și aglomerarea depozitului. GitHub propune automat ștergerea ramurii după merge-ul PR, iar setările depozitului pot fi configurate pentru ștergere automată.