Merge — какво е, типове сливане и механизъм на работа

Какво е Merge?

Merge (сливане) — е фундаментална операция в Git, която обединява промени от един клон (source) в друг (target). В резултат на сливането, целевият клон получава всички commit-ове от изходния клон, които все още не са били в него. В зависимост от ситуацията, Git може да извърши merge по три различни начина.

Основната стойност на merge е запазването на историята: merge commit записва факта на сливане на клоновете, съхранява информация за това кога и кои клонове са били слети. Това улеснява одита на промените, търсенето на регресии и разбирането на хронологията на разработката. В големи проекти merge commit е стандартният начин за интеграция на код.

Според данни от GitLab Flow, merge commit-ове се използват в 73% от екипите, работещи с Git. Алтернативните подходи (rebase, squash) се предпочитат от екипи, ориентирани към линейна история. Изборът на стратегия зависи от размера на екипа, честотата на публикуване и приетите в проекта договорености.

Кога възниква Merge

Merge е необходим, когато разработчикът е завършил работата по дадена функционалност и иска да я интегрира в develop или main. Типичен сценарий: разработчикът създава клон за функционалност от develop, работи в него няколко дни, а през това време в develop се появяват нови commit-ове от други участници. Преди сливането трябва да се обединят промените — и за това се използва merge.

Без merge е невъзможно да се работи съвместно по един код в Git. Всеки път, когато двама разработчици едновременно правят промени в една и съща кодова база, техните клонове се разминават. Merge — е единственият начин тези промени да бъдат обединени обратно без загуба на данни.

Типове сливане в Git

Git поддържа три типа merge, всеки от които е предназначен за свой сценарий. Изборът на тип сливане влияе върху историята на commit-овете, удобството при връщане и четимостта на лога.

Fast-forward merge

Fast-forward възниква, когато целевият клон не е имал нови commit-ове от момента на създаване на изходния. В този случай Git просто премества указателя на целевия клон напред, към последния commit на изходния клон. Историята остава линейна, без merge commit.

# Fast-forward merge: develop не се е променял от създаването на feature
git checkout develop
git merge feature/new-login

# Резултат: указателят на develop се премести в края на feature
# Не е създаден никакъв merge commit

Fast-forward е удобен за краткотрайни клонове, където разработчикът е работил сам. Но този подход има недостатък: информацията, че клонът е съществувал, се губи — всички commit-ове изглеждат като направени директно в develop.

Three-way merge

Three-way merge се изпълнява, когато и двата клона имат нови commit-ове след точката на разминаване. Git създава отделен merge commit с двама родители, който записва факта на сливане на клоновете. Този подход се препоръчва за клонове с функционалности в екипната разработка.

# Принудителен three-way merge с флаг --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Създаден merge commit с подразбиращо се съобщение
# Може да зададете свое съобщение чрез -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Флагът --no-ff гарантира създаването на merge commit, дори ако fast-forward е възможен. Това е най-добрата практика за запазване на информация за разклоненията в проекта.

Squash merge

Squash merge компресира всички commit-ове на изходния клон в един и го прилага към целевия. Историята на функционалността се губи — в клона влиза един commit с всички промени. Това е удобно, когато детайлните commit-ове в клона за функционалност не носят стойност за общата история.

# Squash merge: всички commit-ове на feature са компресирани в един
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash е подходящ за чернови, експериментални клонове и ситуации, когато е важно да се поддържа чистота на историята. Минус — връзката с оригиналните commit-ове се губи, което затруднява връщането на отделни промени.

Стратегии Ours и Theirs

Ours и Theirs — две специални стратегии за merge в Git. Ours напълно игнорира промените от изходния клон, запазвайки само това, което е в целевия. Theirs, напротив, приема версията на изходния клон при всеки конфликт. Тези стратегии са полезни при сливане на големи обеми код, когато предварително е известно коя версия трябва да победи.

Как работи Merge

Механизмът на merge в Git се основава на сравняване на три точки: общия предшественик (merge base), състоянието на изходния клон и състоянието на целевия клон. Git намира merge base — последния commit, общ и за двата клона — и изчислява какви промени са настъпили във всеки клон след разминаването.

• Стъпка 1 — Git определя merge base: последния commit, който съществува и в двата клона
• Стъпка 2 — Git построява два diff-а: от merge base до source и от merge base до target
• Стъпка 3 — Git се опитва да приложи и двата набора промени към merge base
• Стъпка 4 — Ако промените не конфликтират — merge завършва автоматично
• Стъпка 5 — Ако има конфликт — Git спира и изисква разрешаване

Git използва тристранен алгоритъм за сливане, който взема предвид не само двете сравнявани версии на файла, но и техния общ предшественик. Благодарение на това, Git може автоматично да разрешава ситуации, когато промените в единия клон не засягат променените части на другия — дори ако и двата файла са били модифицирани.

Алгоритъм на работа на merge с пример

Нека разгледаме сценарий: двама разработчици работят върху различни файлове в един и същ клон за функционалност. Първият промени LoginActivity.kt, вторият — ProfileFragment.kt. Когато обединят промените си, Git вижда, че промените засягат различни файлове и извършва merge автоматично, без човешка намеса.

Ако и двамата разработчици са променили LoginActivity.kt, но в различни методи — Git също ще се справи автоматично, обединявайки промените ред по ред. Конфликт възниква само ако и двамата са променили едни и същи редове или ако единият е изтрил код, който другият е променил.

Разрешаване на конфликти при Merge

Конфликт при merge възниква, когато Git не може автоматично да обедини промените, защото и двата клона са променили едни и същи редове по различен начин. В този случай Git маркира конфликтните участъци във файловете и очаква ръчно разрешаване от разработчика.

Конфликтните участъци се маркират със специални маркери: <<<<<<< HEAD показва код от целевия клон, ======= — разделителят, >>>>>>> source-branch — код от изходния клон. Разработчикът трябва ръчно да избере кой вариант да запази или да ги обедини.

# 1. Стартирайте merge и вижте конфликта
git merge feature/new-login
# Изход: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Прегледайте списъка с файлове с конфликти
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Разрешете конфликта: редактирайте файла, премахнете маркерите
# 4. Добавете разрешения файл и завършете merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# или: git commit (без --continue)

За разрешаване на конфликти съществуват инструменти: git mergetool отваря визуален merger (Meld, Beyond Compare, VS Code). Много разработчици предпочитат да разрешават конфликти в IDE — IntelliJ IDEA и Android Studio предоставят вграден инструмент с трипанелно сравнение, което значително опростява този процес.

Съвети за разрешаване на конфликти: винаги разбирайте какво прави всяка страна на конфликта, не изтривайте чужд код без да разбирате неговата логика, и ако конфликтът е твърде сложен — включете автора и на двата клона в съвместното разрешаване.

Merge vs Rebase: кога какво да изберем

Изборът между Merge и Rebase — едно от най-честите архитектурни решения в Git. И двата подхода обединяват промени, но го правят по различен начин: merge запазва историята на разклоненията, rebase презаписва историята, правейки я линейна.

• Merge — запазва контекста: вижда се кога и от кой клон е направено сливането. По-добър за публични клонове (develop, main) и екипна работа
• Rebase — създава чиста линейна история без излишни merge commit-ове. По-добър за лични клонове с функционалности преди изпращане за преглед
• Правило: никога не правете rebase на публични клонове, които се използват от други разработчици

Много екипи използват хибриден подход: rebase за привеждане на клона за функционалност до актуалното състояние на develop (git rebase develop), след това merge с флаг --no-ff за фиксиране на сливането. Това дава чиста история вътре във функционалността и информативни точки на сливане на ниво develop.