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 (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 срещу 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". Разработчикът попълва описанието, посочва целевия клон (обикновено 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 pipeline.

Според 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 на нови commits се нулират Approvals, при успешен CI pipeline статусът става Pipeline passed, при грешка — Pipeline failed (сливането се блокира). Може да се конфигурира Auto-merge: MR се слива автоматично след успешен CI и получаване на всички необходими одобрения.

• Draft — чернова, CI се стартира, но сливането е блокирано
• Opened — готов за ревю, назначени ревюиращи, pipeline активен
• Approved — получен необходим брой одобрения
• Merged — промените са слети в целевия клон
• 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 pipeline в Merge Request

При създаване на Merge Request (MR) автоматично се стартира CI/CD pipeline. В GitLab това става чрез файла .gitlab-ci.yml, в GitHub — чрез GitHub Actions workflow. Pipeline включва изграждане на проекта (build), пускане на unit тестове (unit tests), lint-ери (lint), статичен анализ (SAST) и проверка на покритието на кода.

Според GitLab Blog, 2024, статусът на pipeline се показва директно в MR: зелена отметка (passed), червен кръст (failed) или жълт кръг (running). Ако pipeline се провали, GitLab блокира бутона Merge до поправка. В настройките може да се включи „Merge when pipeline succeeds" — автоматично сливане след успешен pipeline.

# .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 — създава отделен commit за сливане, запазвайки цялата история на feature клона. Squash — обединява всички commits на клона в един commit в целевия клон. Fast-Forward — прилага commits линейно без commit за сливане.

Според GitLab Docs, 2025, Squash е предпочитан в проекти с висока плътност на commits (20+ commits в един feature клон). Fast-Forward е задължителен за Trunk-Based Development. Merge Commit се използва в Git Flow за запазване на семантиката на разклоняване.

• Merge Commit — запазва историята, създава commit за сливане, подходящ за Git Flow
• Squash — обединява всички commits в един, чиста история, междинните commits се губят
• Fast-Forward — линейна история без commit за сливане, задължителен в TBD

Най-добри практики: как да напишем добър MR

Качествен Merge Request (MR) съкращава времето за ревю и намалява броя на грешките. Първо правило — един MR решава една задача. Ако промените засягат няколко несвързани функции, те трябва да бъдат разделени на отделни 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 се проверяват по-бавно и с повече грешки
• Тестовете са задължителни: новите функции трябва да бъдат покрити с unit тестове

Шаблони за описание на MR

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