Cum rezolvi conflictele de fuziune (merge) în mod eficient?

Question

Accepted Answer

**Conflictele de fuziune** apar atunci când Git nu poate combina automat modificările (ambele părți au modificat aceleași linii). Rezolvarea lor implică înțelegerea marcherilor de conflict, deciderea rezultatului corect și finalizarea fuziunii. A face acest lucru cu încredere este o abilitate practică importantă. ## Când și de ce apar conflictele ```text Git auto-merges most changes, but a CONFLICT occurs when both branches changed the SAME LINES (or one deleted what the other modified) — Git can't decide, so it asks YOU. → Conflicts are NORMAL in collaboration, not errors — just changes Git can't auto-resolve. ``` ## Înțelegerea marcherilor de conflict ```text <<<<<<< HEAD code from YOUR current branch (the one you're merging INTO) ======= code from the OTHER branch (the one being merged IN) >>>>>>> feature-branch ``` ```text → <<<<<<< to ======= : your side (HEAD) → ======= to >>>>>>> : their side → You edit to the CORRECT final result (one side, the other, or a COMBINATION), then REMOVE all the markers. ``` ## Rezolvarea pas cu pas ```bash git status # see which files have conflicts # open each conflicted file; for each conflict: # decide the correct result (keep yours, theirs, or combine), remove the markers git add # mark the conflict as resolved git commit # (for merge) complete the merge # git merge --abort # or bail out entirely and start over ``` ## Cum să o faci eficient ```text ✓ UNDERSTAND both sides before choosing — don't blindly keep one; know WHY each changed ✓ Use TOOLS — IDE merge tools / git mergetool show both sides + base visually (easier) ✓ TEST after resolving — a resolved conflict can still be logically wrong (compile/run tests) ✓ Communicate with the other author if the changes' intent is unclear ✓ Smaller, frequent merges/pulls → fewer, simpler conflicts (avoid long divergence) ``` ## De ce contează Rezolvarea eficientă a conflictelor de fuziune este o abilitate practică importantă și frecvent necesară, deoarece conflictele sunt o **parte inevitabilă, normală a colaborării** (ori de câte ori mai mulți oameni modifică același cod), iar tratarea lor cu încredere este esențială — totuși, sunt o sursă obișnuită de anxietate și greșeli pentru cei care nu le înțeleg. Înțelegerea că **conflictele sunt normale, nu erori** (doar schimbări pe care Git nu le poate rezolva automat deoarece ambele părți au modificat aceleași linii) elimină teama și le cadrul corect. Abilitățile practice cheie sunt înțelegerea **marcherilor de conflict** (`<<<<<<<` HEAD/partea ta, `=======`, `>>>>>>>` partea lor) pentru a putea citi ce este în conflict, și **procesul de rezolvare** (deciderea rezultatului final corect — păstrând o parte, cealaltă, sau o combinație ponderată — eliminând marcherii, apoi plasând în staging și finalizând fuziunea). Faptul că o faci **eficient** contează: **înțelegerea ambelor părți înainte de a alege** (nu pur și simplu păstrând una, ci știind de ce s-a schimbat fiecare), folosind **instrumente de fuziune** (care arată ambele părți și baza vizual, facilitând rezolvarea), și în mod crucial **testând după rezolvare** (deoarece un conflict rezolvat sintactic poate fi în continuare greșit din punct de vedere logic — compilarea și rularea testelor capturează aceasta) previne introducerea de bug-uri în timpul rezolvării. Știind că fuziunile mai mici și mai frecvente reduc conflictele este o practică preventivă bună. Dintru moment ce conflictele sunt inevitabile în dezvoltarea colaborativă și rezolvarea lor corect (înțelegerea ambelor părți, alegerea rezultatului potrivit și verificare) este necesară pentru a integra munca fără a introduce erori, rezolvarea eficientă a conflictelor de fuziune este o abilitate practică esențială și frecvent aplicată pentru orice dezvoltator care lucrează într-o echipă — transformând o sursă obișnuită de stres într-o sarcină rutină, făcută cu încredere, și o competență importantă care afectează direct corectitudinea codului în timpul integrării inevitabile a modificărilor concurente.