Сливане (merge) — какво е това, как работи merge и стратегии за сливане

Какво е merge в Git

Merge — това е командата git merge, която обединява промени от посочения клон в текущия клон. Git намира общия прародител (общ базов комит), изчислява diff на всеки клон спрямо прародителя и създава merge-комит, съдържащ обединения набор от промени. Резултат — целевият клон се допълва с всички промени от слетия клон.

Синтаксис: намирайки се в целевия клон (напр. main), изпълни git merge feature. Git автоматично създава merge-комит, ако няма конфликти. В подразбиращото се съобщение на merge-комита се посочва: „Merge branch ’feature’ into main“. Съобщението може да се промени чрез флага -m или да се редактира в отворения редактор.

Merge е неразрушителна операция. За разлика от rebase, merge не пипа съществуващите комитове: те остават със същите хешове, автори и дати. Това прави merge единствения безопасен начин за сливане на клонове, по които едновременно работят няколко разработчика. Ако нещо се обърка, merge може да бъде отменен с командата git merge --abort.

# Превключи към целевия клон
git checkout main

# Слей feature-клона
git merge feature

# Резултат — merge-комит с двама родители
git log --oneline --graph

# Слей с персонализирано съобщение
git merge feature -m "feat: integrate authentication module"

Видове merge: regular, squash, fast-forward

Git поддържа три режима на сливане, които се избират в зависимост от желания резултат. Regular merge (по подразбиране) създава merge-комит. Squash merge обединява всички комитове на feature-клона в един. Fast-forward — премества указателя на клона напред без създаване на комит, ако е възможно. Изборът на режим зависи от workflow-а на екипа и правилата за история.

Regular merge (--no-ff) — създава merge-комит дори ако сливането може да се извърши като fast-forward. Препоръчва се за main-клона: merge-комитът изрично маркира момента на интеграция на функцията и позволява лесно връщане на всички промени от feature-клона чрез едно revert на merge-комита. GitHub използва този режим по подразбиране при сливане на PR чрез бутона Merge.

Squash merge (--squash) — събира всички комитове на feature-клона в един комит в целевия клон. Полезен, когато черновата история на feature-клона не трябва да влиза в main. Недостатък: връзката с оригиналните комитове се губи — не може да се види как функцията е била разработвана стъпка по стъпка. GitHub използва този режим при избор на „Squash and merge“ в PR.

Fast-forward (--ff) — ако целевият клон няма нови комитове след отделянето на функцията, Git просто премества указателя напред, без да създава merge-комит. Историята остава линейна. Флагът --no-ff принудително създава merge-комит, --ff-only ще завърши с грешка, ако fast-forward не е възможен.

# Принудителен merge-комит (препоръчва се за main)
git merge --no-ff feature

# Squash merge — всички комитове в един
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward само ако е възможно
git merge --ff-only feature

# Прекрати конфликтното сливане
git merge --abort

Стратегии за сливане в Git

Стратегиите за сливане определят алгоритъма, който Git използва за обединяване на промени. Всяка стратегия е подходяща за различни сценарии. Git автоматично избира подходящата стратегия, но разработчикът може да я посочи изрично чрез флага --strategy. Разбирането на стратегиите помага да се предвиди поведението на Git при сложни сливания.

Recursive — стратегия по подразбиране за сливане на два клона. Git намира общия прародител, изчислява промените във всеки клон и ги обединява. Ако общият прародител бъде намерен, recursive правилно обработва преименуването на файлове и добавянето на нови. При конфликти recursive може да използва допълнителни опции: ours (автоматично избира нашата версия) и theirs (избира тяхната).

Octopus — за едновременно сливане на повече от два клона: git merge feature1 feature2 feature3. Octopus не поддържа разрешаване на конфликти — всички конфликти трябва да бъдат разрешени преди извикването на командата. Използва се рядко, основно за обединяване на няколко независими клона, които гарантирано не конфликтират (напр. различни модули).

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

Разрешаване на merge-конфликти

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

Процес на разрешаване: Git маркира конфликтните файлове с маркери. Във файла се появяват участъци с <<<<<<< HEAD (нашата версия), ======= (разделител) и >>>>>>> feature (тяхната версия). Разработчикът ръчно редактира конфликтния участък, избира нужните редове от двете версии, премахва маркерите, записва файла и го добавя в индекса чрез git add.

За визуално разрешаване на конфликти Git поддържа mergetool — външен инструмент за сравнение. Популярни mergetool инструменти: Meld, KDiff3, Beyond Compare, VS Code (вграден редактор на конфликти). Mergetool показва три панела: нашата версия, тяхната версия и резултата. Разработчикът визуално избира блоковете код за включване в крайния файл.

# Започни сливане и открий конфликт
git merge feature
# КОНФЛИКТ (съдържание): Конфликт при сливане в src/main.swift

# Провери конфликтните файлове
git status

# Отвори визуален mergetool
git mergetool

# След разрешаване — добави и комитвай
git add src/main.swift
git commit

# Прекрати сливане
git merge --abort

Кога да изберем merge вместо rebase

Merge е за предпочитане пред rebase в няколко ключови ситуации. Първо: при работа с публични клонове, достъпни за други разработчици. Merge не презаписва историята и колегите могат безопасно да се синхронизират. Rebase в публичен клон ще създаде разминаваща се история и конфликти за всички, които вече са получили старите комитове.

Втора ситуация: при завършване на feature-клон. Повечето екипи предпочитат merge (с флага --no-ff) в main, за да фиксират момента на интеграция на функцията. Това опростява навигацията в историята и позволява лесно връщане на цялата функция чрез един git revert на merge-комита. GitHub Flow по подразбиране предлага три опции за merge: прост merge, squash merge и rebase merge.

Трета ситуация: при работа с pull request, който е преминал ревю. GitHub и GitLab предлагат бутон за merge с различни опции. Merge (Create a merge commit) — пълна история с merge-комит. Squash and merge — чиста история без детайли за разработка. Rebase and merge — линейна история без merge-комит, но с презаписване на комитове. Изборът зависи от правилата на екипа.

• Публични клонове (main, develop) — само merge, никога rebase.
• Завършване на PR — merge с --no-ff за фиксиране на момента на интеграция.
• Клонове с чужди комитове — merge не презаписва чуждата работа.
• Преди издаване — merge е по-безопасен, тъй като има по-малко рискове.
• Съвместен клон — ако по клона работят няколко разработчика, merge е задължителен.

Най-добри практики за сливане на клонове

Първо правило: винаги бъди на актуалната версия на целевия клон преди merge. Изпълни git checkout main && git pull, преди да слееш функцията. Това минимизира конфликтите и гарантира, че merge-комитът ще съдържа всички актуални промени. Ако целевият клон е отишъл твърде напред, първо изпълни git merge main вътре в feature-клона за разрешаване на конфликти в неговия контекст.

Второ правило: тествай кода след merge. Merge може да промени поведението, дори и ако не е имало конфликти. CI/CD тръбопроводът трябва да пусне тестове на merge-комита преди изпращане в продукция. Някои екипи използват merge gates — задължителни проверки, които блокират merge до тяхното преминаване.

Трето правило: документирай merge-комитовете. Стандартното съобщение „Merge branch ’feature’ into main“ е малко полезно. Препоръчва се добавяне на описание на това, което е било слято: „Merge authentication module: login, registration, password recovery“. Това опростява анализа на историята и търсенето на регресии. В големи проекти merge-комитовете се генерират автоматично от името на PR.

• Актуалност — преди merge се увери, че целевият клон е обновен (git pull).
• Тестване — CI/CD трябва да пусне тестове на резултатния merge-комит.
• Описателни съобщения — посочи в merge-комита коя функция е била слята.
• Честота — сливай feature-клоновете възможно най-рано и често (максимум седмица).
• Отмяна — git revert на merge-комита връща цялата функция напълно.