Merge Request (MR): що це, як створити та процес рев'ю

Що таке Merge Request (MR)?

Merge Request (MR) — запит на інтеграцію змін з однієї гілки Git до іншої, який ініціює процес код-рев'ю та автоматичної перевірки. На відміну від прямого злиття через консоль, MR створює формальну процедуру: розробник описує зміни, призначає рев'юерів, запускає CI/CD та отримує зворотний зв'язок до застосування змін. Це ключовий елемент GitLab, але аналогічний механізм у GitHub називається Pull Request (PR).

За даними GitLab Documentation, 2026, у GitLab створюється понад 80 мільйонів Merge Request щорічно. Кожен MR містить чотири основні компоненти: опис (description) з контекстом змін, список комітів (commits), різницю в коді (diff) та обговорення (discussion thread). Без одного з цих елементів MR вважається неповним.

Merge Request (MR) вирішує три завдання: запобігає прямим змінам у захищених гілках (main, develop), забезпечує контроль якості через рев'ю та зберігає історію обговорень для майбутніх розробників. У GitLab статус MR відображається в інтерфейсі з кольоровою індикацією: сірий для Draft, помаранчевий для очікування, зелений для Approved, фіолетовий для Merged та червоний для Closed.

Термінологія: MR, PR та CR

У різних Git-платформах Merge Request називається по-різному. GitLab використовує «Merge Request» (MR), GitHub — «Pull Request» (PR). Аналогія — Change Request (CR) у Gerrit. Всі три позначають один і той самий процес: запит на інтеграцію змін через код-рев'ю. Вибір терміна залежить лише від платформи, що використовується в проекті.

# Створити гілку зі змінами
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Створити MR можна через UI GitLab/GitHub або CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: у чому різниця між GitLab та GitHub

Merge Request у GitLab та Pull Request у GitHub — це функціонально однакові механізми з різними назвами. Різниця зумовлена історією: GitLab спочатку позиціонувався як Self-Hosted альтернатива GitHub та обрав термін «merge request» для процесу злиття. GitHub, запущений раніше, використав «pull request» — запит «потягнути» (pull) зміни в основну гілку.

За даними GitHub Docs, 2024, обидва інструменти підтримують однаковий набір функцій: опис з Markdown, призначення рев'юерів, коментування конкретних рядків коду, статуси перевірок та автоматичне злиття при виконанні умов. Відмінності стосуються інтерфейсу та додаткових можливостей.

Як створити Merge Request: покрокова інструкція

Створення Merge Request (MR) починається з публікації гілки зі змінами у віддаленому репозиторії. Після push у GitLab або GitHub в інтерфейсі з'являється кнопка «Create Merge Request» або «Compare & Pull Request». Розробник заповнює опис, вказує target-гілку (зазвичай develop або main), призначає рев'юерів та прикріплює мітки (labels).

За даними GitLab Documentation, 2025, стандартний MR містить заголовок до 72 символів, опис із шаблоном (template) та посилання на задачу (issue). Опис має відповідати на питання: що зроблено, чому, як тестувалося. GitLab підтримує авто-закриття issue при мержі через ключові слова Closes, Fixes, Resolves.

# Приклад шаблону .gitlab/merge_request_templates/default.md
## What does this MR do?

[Краткое описание изменений: что и зачем]

## How to test

1. Запустить ./gradlew test
2. Проверить LoginActivity с тестовым токеном
3. Убедиться, что нет регрессии в AuthManager

## Related issues

Closes #142

Життєвий цикл MR: від Draft до Merged

Merge Request (MR) проходить п'ять статусів у GitLab. Перший — Draft (чернетка), позначається префіксом «Draft:» у заголовку та блокує злиття. Після готовності розробник прибирає Draft, і MR переходить у статус Opened — починається код-рев'ю та запускається CI/CD пайплайн.

За даними GitLab Docs, 2024, у статусі Opened рев'юери переглядають diff, залишають коментарі та запитують зміни через Resolve Threads. Коли всі треди закриті та CI/CD проходить успішно, відповідальний розробник ставить Approve. Після цього MR можна змержити кнопкою Merge або дочекатися автоматичного злиття (Auto-merge).

GitLab підтримує три варіанти фінального статусу: Merged (успішно влито), Closed (закрито без злиття, наприклад, при відмові від фічі) та Reopened (повторне відкриття після закриття). Кожен статус логується в Activity Timeline MR для аудиту.

Автоматичні статуси та тригери

GitLab автоматично оновлює статус Merge Request при настанні подій: при push нових комітів скидаються Approvals, при успішному CI пайплайні статус стає Pipeline passed, при failure — Pipeline failed (мерж блокується). Можна налаштувати Auto-merge: MR вливається автоматично після успішного CI та отримання всіх необхідних апрувів.

• Draft — чернетка, CI запускається, але мерж заблоковано
• Opened — готовий до рев'ю, призначені рев'юери, пайплайн активний
• Approved — отримано необхідну кількість апрувів
• Merged — зміни влито в target-гілку
• Closed — закрито без злиття

Правила код-рев'ю в Merge Request

Код-рев'ю в Merge Request (MR) — обов'язковий етап у більшості комерційних проектів. За даними дослідження SmartBear, 2023, код-рев'ю з MR скорочує кількість дефектів на 30–60% та прискорює онбординг нових розробників. Основне правило — кожен MR перевіряє щонайменше один, а краще два розробники, які не брали участі в написанні коду.

Перевірка MR включає п'ять критеріїв: коректність логіки, відповідність код-стайлу, покриття тестами, безпека та продуктивність. У GitLab можна налаштувати Required Approvals — обов'язкову кількість апрувів перед мержем, наприклад, 2 апруви для main та 1 для develop.

Обговорення в MR ведеться в Threads — коментарях до конкретних рядків коду. Кожен тред має бути resolved (закритий) до злиття. Для прискорення рев'ю рекомендується обмежувати розмір MR: 200–400 рядків змін. Згідно з даними Google Research (2022), MR об'ємом понад 400 рядків перевіряються на 30% менш ефективно.

CI/CD пайплайн в Merge Request

При створенні Merge Request (MR) автоматично запускається CI/CD пайплайн. У GitLab це відбувається через файл .gitlab-ci.yml, у GitHub — через GitHub Actions workflow. Пайплайн включає збірку проекту (build), прогін модульних тестів (unit tests), лінтери (lint), статичний аналіз (SAST) та перевірку покриття коду.

За даними GitLab Blog, 2024, статус пайплайну відображається прямо в MR: зелена галочка (passed), червоний хрест (failed) або жовте коло (running). Якщо пайплайн впав, GitLab блокує кнопку Merge до виправлення. У налаштуваннях можна включити «Merge when pipeline succeeds» — автоматичний мерж після успішного пайплайну.

# .gitlab-ci.yml — приклад для Android-проекту
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Методи злиття: Squash, Merge Commit, Fast-Forward

GitLab та GitHub пропонують три методи злиття для Merge Request. Вибір залежить від політики команди та необхідної чистоти історії. Merge Commit — створює окремий коміт злиття, зберігаючи всю історію feature-гілки. Squash — об'єднує всі коміти гілки в один коміт на target-гілці. Fast-Forward — застосовує коміти лінійно без коміту злиття.

За даними GitLab Docs, 2025, Squash є кращим для проектів з високою щільністю комітів (20+ комітів в одній feature-гілці). Fast-Forward обов'язковий для Trunk-Based Development. Merge Commit використовується в Git Flow для збереження семантики розгалуження.

• Merge Commit — зберігає історію, створює коміт злиття, підходить для Git Flow
• Squash — об'єднує всі коміти в один, чиста історія, втрачаються проміжні коміти
• Fast-Forward — лінійна історія без коміту злиття, обов'язковий у TBD

Кращі практики: як писати хороший MR

Якісний Merge Request (MR) скорочує час рев'ю та знижує кількість помилок. Перше правило — один MR вирішує одне завдання. Якщо зміни зачіпають кілька unrelated фіч, їх потрібно розбити на окремі MR. Друге — заголовок MR має бути інформативним: «Add OAuth2 authentication with Google provider» замість «Fix stuff» або «Update code».

За даними Google Engineering Practices, 2024, хороший MR містить опис контексту: чому зміни необхідні, як вони тестувалися, які є ризики. Розмір MR не повинен перевищувати 400 рядків змін. Якщо обсяг більший — завдання потрібно декомпозувати на підзадачі. Для документації та тестів винятки допустимі, але з поясненням.

Merge Request (MR) повинен включати авто-тести на нову функціональність. У GitLab можна налаштувати політику Coverage Check — MR автоматично блокується, якщо покриття коду впало нижче порогу (наприклад, 80%). Це гарантує, що нова функціональність не знижує загальну якість проекту.

• Один MR — одне завдання: декомпозуйте великі зміни на кілька маленьких MR
• Опис із шаблоном: використовуйте .gitlab/merge_request_templates для єдинообразності
• Розмір до 400 рядків: великі MR перевіряються повільніше та з більшою кількістю помилок
• Тести обов'язкові: нові фічі повинні покриватися модульними тестами

Шаблони опису MR

GitLab підтримує шаблони Merge Request через файли .gitlab/merge_request_templates/. Шаблон включає секції: що зроблено, як тестувати, пов'язані завдання та чек-лист. Використання шаблонів прискорює створення MR та гарантує, що розробники не забудуть вказати важливу інформацію. В описі MR обов'язково вказуються пов'язані issue (Closes #N) для авто-закриття завдань при мержі.