Змержити гілки — що це, способи злиття та вирішення конфліктів

Що таке мерж у Git

Merge у Git — це операція об’єднання двох або більше історій розробки в одну. Коли розробник змерджує гілку, Git автоматично знаходить спільного предка (base commit) і створює новий коміт злиття, що включає зміни з обох гілок. Three-way merge — стандартний алгоритм, що порівнює три стани: спільний предок, перша гілка та друга гілка.

Процес мержу починається з команди git merge. Git визначає точку розходження гілок і послідовно застосовує зміни з вихідної гілки поверх цільової. Якщо зміни не конфліктують, Git виконує fast-forward або створює merge commit залежно від налаштувань. Fast-forward — сценарій, при якому цільова гілка просто переміщується на коміти вихідної.

# Переключитися на цільову гілку і змержити
git checkout main
git merge feature/payment-module

# Змержити з явним no-fast-forward
git merge --no-ff feature/payment-module

# Скасувати мерж, якщо конфлікти надто складні
git merge --abort

Прапорець --no-ff (no fast-forward) примусово створює merge commit навіть при можливості fast-forward. Це зберігає інформацію про те, що зміни були зроблені в окремій гілці. Багато команд віддають перевагу саме такому підходу для збереження розгалуження історії в явному вигляді.

Способи злиття гілок

У Git існують три основні стратегії злиття гілок, кожна з яких підходить для певного сценарію. Вибір стратегії залежить від культури команди та вимог до чистоти історії проекту.

Standard merge створює merge commit із двома батьками. Повна історія зберігається, але граф розгалуження ускладнюється. Squash merge об’єднує всі коміти feature-гілки в один і застосовує його поверх цільової гілки — історія стає лінійною та чистою, але втрачається інформація про проміжні етапи.

Rebase, хоч і не є повноцінним мержем, досягає того ж результату — зміни однієї гілки переносяться поверх іншої. Різниця в тому, що історія переписується: коміти feature-гілки створюються заново поверх останнього коміту цільової гілки. Це дає ідеально лінійну історію, але вимагає force push при відправці.

Як вирішувати конфлікти при мержі

Конфлікт при мержі виникає, коли в двох гілках змінено одні й ті ж рядки файлу. Git не може автоматично визначити, який варіант зберегти, і вимагає втручання розробника. Конфлікти відображаються у файлах у вигляді спеціальних маркерів: <<<<<<<, =======, >>>>>>>.

Процес вирішення конфлікту включає кілька кроків. Спочатку розробник відкриває конфліктуючий файл і вручну вибирає потрібні зміни. Важливо не просто вибрати одну з версій, а зрозуміти логіку обох змін і прийняти коректне рішення. Після редагування файлу маркери конфлікту видаляються, і зміни додаються до staging area через git add.

# Переглянути список конфліктуючих файлів
git status

# Запустити mergetool (наприклад, VS Code, IntelliJ)
git mergetool

# Після вирішення всіх конфліктів
git add .
git merge --continue

# Або скасувати мерж повністю
git merge --abort

Використання візуальних merge tools значно прискорює вирішення конфліктів. VS Code, IntelliJ IDEA та GitKraken надають інтерфейси з трьома панелями: поточна гілка, вхідна гілка та результат. Інструмент git mergetool автоматично відкриває налаштований редактор для кожного конфліктуючого файлу.

Найкращий спосіб уникнути складних конфліктів — регулярна синхронізація feature-гілки з основною. Якщо розробник змерджує main у свою гілку раз на день, конфлікти будуть невеликими та легко вирішуваними. Накопичення змін протягом тижня гарантує складні конфлікти з високим ризиком помилок.

Коли використовувати rebase замість merge

Rebase та merge — два способи об’єднання змін, і вибір між ними часто викликає суперечки в командах. Rebase переносить коміти з однієї гілки поверх іншої, переписуючи історію. Merge створює новий коміт злиття, зберігаючи історію розгалуження. Кожен підхід має свої переваги та обмеження.

Rebase доречний, коли розробник працює у своїй локальній feature-гілці та хоче отримати чисту лінійну історію перед створенням Pull Request. Після rebase всі коміти вибудовуються послідовно, без зайвих merge commit. Однак rebase вимагає force push і незастосовний до гілок, у яких працюють кілька людей одночасно.

• Rebase — для особистих feature-гілок, де потрібна чиста історія
• Merge — для спільних гілок та фіксації моменту злиття
• Squash — коли feature-гілка містить багато дрібних комітів-чернеток

Золоте правило Git: не використовуй rebase на комітах, які вже були відправлені в спільний репозиторій. Це гарантує, що історія в спільній гілці залишається незмінною, та інші розробники не зіткнуться з дубльованими або втраченими комітами. Для інтеграції feature-гілки в основну використовуй merge через Pull Request.

Найкращі практики злиття гілок

Правильний процес мержу — основа стабільної розробки. У сучасній командній роботі мерж виконується не через консоль, а через Pull Request на GitHub або Merge Request у GitLab. PR проходить код-рев’ю, автоматичні перевірки CI та лише після цього мержиться в основну гілку.

Перша практика — мержити тільки після проходження всіх перевірок. CI-пайплайн має зібрати проект, запустити тести та перевірити якість коду. Якщо хоча б одна перевірка не пройшла, мерж блокується. Сучасні платформи (GitHub, GitLab) мають вбудований захист: branch protection rules автоматично блокують мерж при падінні CI.

Друга практика — ніколи не мержити зламаний код. Перед мержем розробник має переконатися, що його зміни не ламають білд і не регресують існуючу функціональність. Для цього існують автоматичні тести та code review.

Третя практика — чистити feature-гілки після мержу. Гілка, яка вже змерджена, має бути видалена. Це запобігає плутанині та захаращенню репозиторію. GitHub автоматично пропонує видалити гілку після мержу PR, а налаштування репозиторію можна налаштувати на автоматичне видалення.