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". Програмер попуњава опис, означава циљну грану (обично 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, при грешци — Pipeline failed (спајање је блокирано). Може се подесити Auto-merge: MR се спаја аутоматски након успјешног CI и добијања свих потребних одобрења.

• Draft — нацрт, CI се покреће, али спајање је блокирано
• Opened — спреман за преглед, именовани рецензенти, пајплајн активан
• 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 пајплајн у Merge Request

При креирању Merge Request (MR) аутоматски се покреће CI/CD пајплајн. У GitLab се то дешава кроз датотеку .gitlab-ci.yml, у GitHub — кроз GitHub Actions workflow. Пајплајн укључује изградњу пројекта (build), покретање јединичних тестова (unit tests), lintере (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 — ствара засебан комит спајања, чувајући цијелу историју функционалне гране. Squash — обједињује све комитове гране у један комит на циљној грани. Fast-Forward — примјењује комитове линеарно без комита спајања.

Према GitLab Docs, 2025, Squash је пожељан у пројектима са високом густином комитова (20+ комитова у једној функционалној грани). Fast-Forward је обавезан за Trunk-Based Development. Merge Commit се користи у Git Flow за очување семантике гранања.

• Merge Commit — чува историју, ствара комит спајања, погодан за Git Flow
• Squash — обједињује све комитове у један, чиста историја, губе се међукомитови
• Fast-Forward — линеарна историја без комита спајања, обавезан у 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 се провјеравају спорије и са већим бројем грешака
• Тестови обавезни: нове функције треба да буду покривене јединичним тестовима

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

GitLab подржава шаблоне Merge Request кроз датотеке .gitlab/merge_request_templates/. Шаблон укључује секције: шта је урађено, како тестирати, повезани задаци и контролна листа. Коришћење шаблона убрзава креирање MR и гарантује да програмери не забораве да наведу важне информације. У опису MR обавезно се наводи повезани issue (Closes #N) за аутоматско затварање задатака при спајању.