Merge Request (MR): nədir, necə yaratmaq və icmal prosesi

Merge Request (MR) nədir?

Merge Request (MR) — bir Git budağından digərinə dəyişikliklərin inteqrasiyası üçün sorğu, kod icmalı və avtomatik yoxlama prosesini başladır. Birbaşa konsol vasitəsilə birləşdirmədən fərqli olaraq, MR formal prosedur yaradır: inkişaf etdirici dəyişiklikləri təsvir edir, rəyçilər təyin edir, CI/CD-ni işə salır və dəyişikliklər tətbiq edilməzdən əvvəl geribildirim alır. Bu GitLab-ın əsas elementidir, lakin GitHub-da analoji mexanizm Pull Request (PR) adlanır.

GitLab Documentation, 2026-ya görə, GitLab-da hər il 80 milyondan çox Merge Request yaradılır. Hər MR dörd əsas komponentdən ibarətdir: dəyişiklik konteksti ilə təsvir (description), commit siyahısı (commits), kod fərqi (diff) və müzakirə (discussion thread). Bu elementlərdən biri olmadan MR natamam sayılır.

Merge Request (MR) üç vəzifəni həll edir: qorunan budaqlarda (main, develop) birbaşa dəyişikliklərin qarşısını alır, icmal vasitəsilə keyfiyyətə nəzarəti təmin edir və gələcək inkişaf etdiricilər üçün müzakirə tarixini saxlayır. GitLab-da MR statusu interfeysdə rəng göstəriciləri ilə əks olunur: boz — Draft, narıncı — gözləmə, yaşıl — Approved, bənövşəyi — Merged və qırmızı — Closed.

Terminologiya: MR, PR və CR

Müxtəlif Git platformalarında Merge Request fərqli adlanır. GitLab “Merge Request” (MR), GitHub isə “Pull Request” (PR) istifadə edir. Analoji — Gerrit-də Change Request (CR). Hər üçü eyni prosesi bildirir: kod icmalı vasitəsilə dəyişikliklərin inteqrasiyası sorğusu. Termin seçimi yalnız layihədə istifadə olunan platformadan asılıdır.

# Dəyişikliklərlə budaq yaradın
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR GitLab/GitHub UI və ya CLI vasitəsilə yaradıla bilər:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: GitLab və GitHub arasında fərq nədir

Merge Request GitLab-da və Pull Request GitHub-da — bunlar funksional olaraq eyni mexanizmlərdir, yalnız adları fərqlidir. Fərq tarixlə bağlıdır: GitLab əvvəlcə GitHub-a Self-Hosted alternativ olaraq mövqelənmiş və birləşdirmə prosesi üçün “merge request” terminini seçmişdir. Daha əvvəl işə salınmış GitHub isə “pull request” — dəyişiklikləri əsas budağa “cəkmək” (pull) sorğusu istifadə etmişdir.

GitHub Docs, 2024-ə görə, hər iki alət eyni funksiyalar dəstini dəstəkləyir: Markdown ilə təsvir, rəyçilərin təyin edilməsi, konkret kod sətirlərinə şərh yazmaq, yoxlama statusları və şərtlər yerinə yetirildikdə avtomatik birləşdirmə. Fərqlər interfeys və əlavə imkanlarla bağlıdır.

Merge Request necə yaradılır: addım-addım təlimat

Merge Request (MR) yaratmaq dəyişikliklərlə budağın uzaq depozitorda yayımlanması ilə başlayır. GitLab və ya GitHub-a push-dan sonra interfeysdə “Create Merge Request” və ya “Compare & Pull Request” düyməsi görünür. İnkişaf etdirici təsviri doldurur, hədəf budağı (adətən develop və ya main) göstərir, rəyçilər təyin edir və etiketlər (labels) əlavə edir.

GitLab Documentation, 2025-ə görə, standart MR 72 simvola qədər başlıq, şablon (template) ilə təsvir və tapşırığa (issue) keçid ehtiva edir. Təsvir suallara cavab verməlidir: nə edilib, niyə, necə test edilib. GitLab Closes, Fixes, Resolves açar sözləri vasitəsilə birləşmə zamanı issue-lərin avtomatik bağlanmasını dəstəkləyir.

# .gitlab/merge_request_templates/default.md şablon nümunəsi
## What does this MR do?

[Dəyişikliklərin qısa təsviri: nə və nəyə görə]

## How to test

1. İşə salmaq ./gradlew test
2. Yoxlamaq LoginActivity test tokeni ilə
3. Reqressiya olmadığını yoxlayın: AuthManager

## Related issues

Closes #142

MR-nin həyat dövrü: Draft-dan Merged-ə qədər

Merge Request (MR) GitLab-da beş status keçir. Birincisi — Draft (qaralama), başlıqda “Draft:” prefiksi ilə işarələnir və birləşməni bloklayır. Hazır olduqdan sonra inkişaf etdirici Draft-ı çıxarır və MR Opened statusuna keçir — kod icmalı başlayır və CI/CD pipeline işə düşür.

GitLab Docs, 2024-ə görə, Opened statusunda rəyçilər diff-ə baxır, şərhlər buraxır və Resolve Threads vasitəsilə dəyişiklik tələb edir. Bütün mövzular bağlandıqda və CI/CD uğurla keçdikdə, məsul inkişaf etdirici Approve qoyur. Bundan sonra MR Merge düyməsi ilə birləşdirilə və ya avtomatik birləşməni (Auto-merge) gözləyə bilər.

GitLab üç son status variantını dəstəkləyir: Merged (uğurla birləşdirilib), Closed (birləşmədən bağlanıb, məsələn, funksiyadan imtina) və Reopened (bağlandıqdan sonra yenidən açılıb). Hər status audit üçün Activity Timeline MR-da qeyd olunur.

Avtomatik statuslar və tetikleyiciler

GitLab hadisələr baş verdikdə Merge Request statusunu avtomatik yeniləyir: yeni commitlər push edildikdə Approvals sıfırlanır, uğurlu CI pipeline-da status Pipeline passed olur, xəta olduqda — Pipeline failed (birləşmə bloklanır). Auto-merge konfiqurasiya edilə bilər: MR uğurlu CI və bütün tələb olunan təsdiqlər alındıqdan sonra avtomatik birləşir.

• Draft — qaralama, CI işə düşür, lakin birləşmə bloklanıb
• Opened — icmala hazır, rəyçilər təyin edilib, pipeline aktivdir
• Approved — tələb olunan sayda təsdiq alınıb
• Merged — dəyişikliklər hədəf budağa birləşdirilib
• Closed — birləşmədən bağlanıb

Merge Request-də kod icmalı qaydaları

Merge Request (MR)-də kod icmalı — kommersiya layihələrinin əksəriyyətində məcburi mərhələdir. SmartBear, 2023 tədqiqatına görə, MR ilə kod icmalı qüsurların sayını 30–60% azaldır və yeni inkişaf etdiricilərin adaptasiyasını sürətləndirir. Əsas qayda — hər MR ən azı bir, daha yaxşı iki, kodun yazılmasında iştirak etməmiş inkişaf etdirici tərəfindən yoxlanılmalıdır.

MR yoxlanışı beş meyarı əhatə edir: məntiqin düzgünlüyü, kod stilinin uyğunluğu, testlə əhatə olunma, təhlükəsizlik və performans. GitLab-da Required Approvals — birləşmədən əvvəl məcburi təsdiq sayını konfiqurasiya etmək olar, məsələn, main üçün 2, develop üçün 1 təsdiq.

MR-də müzakirə Threads — kodun konkret sətirlərinə şərhlər şəklində aparılır. Hər mövzu birləşmədən əvvəl həll edilməlidir (resolved). İcmalı sürətləndirmək üçün MR ölçüsünü məhdudlaşdırmaq tövsiyə olunur: 200–400 sətir dəyişiklik. Google Research (2022) məlumatlarına görə, 400 sətirdən çox MR 30% daha az effektiv yoxlanılır.

Merge Request-də CI/CD pipeline

Merge Request (MR) yaradıldıqda CI/CD pipeline avtomatik işə düşür. GitLab-da bu .gitlab-ci.yml faylı vasitəsilə, GitHub-da isə GitHub Actions workflow ilə baş verir. Pipeline layihənin qurulması (build), vahid testlərin (unit tests) işə salınması, linterlər (lint), statik analiz (SAST) və kod əhatəsinin yoxlanılmasını əhatə edir.

GitLab Blog, 2024-ə görə, pipeline statusu birbaşa MR-də göstərilir: yaşıl işarə (passed), qırmızı xaç (failed) və ya sarı dairə (running). Pipeline uğursuz olarsa, GitLab düzəliş edilənə qədər Merge düyməsini bloklayır. Parametrlərdə “Merge when pipeline succeeds” — uğurlu pipeline-dan sonra avtomatik birləşmə aktivləşdirilə bilər.

# .gitlab-ci.yml — Android layihəsi üçün nümunə
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Birləşdirmə üsulları: Squash, Merge Commit, Fast-Forward

GitLab və GitHub Merge Request üçün üç birləşdirmə üsulu təklif edir. Seçim komandanın siyasətindən və tələb olunan tarix təmizliyindən asılıdır. Merge Commit — ayrıca birləşmə commiti yaradır, feature budağının bütün tarixini saxlayır. Squash — budağın bütün commitlərini hədəf budaqda bir commitdə birləşdirir. Fast-Forward — commitləri birləşmə commiti olmadan xətti şəkildə tətbiq edir.

GitLab Docs, 2025-ə görə, Squash yüksək commit sıxlığı olan layihələrdə (bir feature budağında 20+ commit) üstünlük təşkil edir. Fast-Forward Trunk-Based Development üçün məcburidir. Merge Commit Git Flow-da budaqlanma semantikasını qorumaq üçün istifadə olunur.

• Merge Commit — tarixi saxlayır, birləşmə commiti yaradır, Git Flow üçün uyğundur
• Squash — bütün commitləri birində birləşdirir, təmiz tarix, ara commitlər itir
• Fast-Forward — birləşmə commiti olmadan xətti tarix, TBD-də məcburidir

Ən yaxşı təcrübələr: yaxşı MR necə yazılmalı

Keyfiyyətli Merge Request (MR) icmal vaxtını azaldır və səhvlərin sayını azaldır. Birinci qayda — bir MR bir tapşırığı həll edir. Dəyişikliklər bir neçə əlaqəsiz funksiyaya toxunursa, onları ayrı MR-lərə bölmək lazımdır. İkincisi — MR başlığı məlumatlandırıcı olmalıdır: “Fix stuff” və ya “Update code” əvəzinə “Add OAuth2 authentication with Google provider”.

Google Engineering Practices, 2024-ə görə, yaxşı MR kontekst təsviri ehtiva edir: dəyişikliklər niyə lazımdır, necə test edilib, hansı risklər var. MR ölçüsü 400 sətir dəyişiklikdən çox olmamalıdır. Həcm daha böyükdürsə — tapşırıq alt tapşırıqlara bölünməlidir. Sənədlər və testlər üçün istisnalar icazəlidir, lakin izahatla.

Merge Request (MR) yeni funksionallıq üçün avtomatik testlər ehtiva etməlidir. GitLab-da Coverage Check siyasəti konfiqurasiya edilə bilər — kod əhatəsi həddən (məsələn, 80%) aşağı düşərsə, MR avtomatik bloklanır. Bu, yeni funksionallığın layihənin ümumi keyfiyyətini aşağı salmamasını təmin edir.

• Bir MR — bir tapşırıq: böyük dəyişiklikləri bir neçə kiçik MR-ə bölün
• Şablonla təsvir: vahidlik üçün .gitlab/merge_request_templates istifadə edin
• Ölçü 400 sətirə qədər: böyük MR-lər daha yavaş və daha çox səhvlə yoxlanılır
• Testlər məcburidir: yeni funksiyalar vahid testlərlə əhatə olunmalıdır

MR təsvir şablonları

GitLab Merge Request şablonlarını .gitlab/merge_request_templates/ faylları vasitəsilə dəstəkləyir. Şablon bölmələri ehtiva edir: nə edilib, necə test etmək, əlaqəli tapşırıqlar və yoxlama siyahısı. Şablonlardan istifadə MR yaradılmasını sürətləndirir və inkişaf etdiricilərin vacib məlumatları qeyd etməyi unutmamasını təmin edir. MR təsvirində birləşmə zamanı tapşırıqların avtomatik bağlanması üçün əlaqəli issue (Closes #N) mütləq göstərilir.