Merge Request (MR): nima, qanday yaratish va ko'rib chiqish jarayoni

Merge Request (MR) nima?

Merge Request (MR) — bir Git filialidan ikkinchisiga o'zgarishlarni integratsiya qilish so'rovi, kod ko'rib chiqish va avtomatik tekshirish jarayonini boshlaydi. Konsol orqali to'g'ridan-to'g'ri birlashtirishdan farqli o'laroq, MR rasmiy tartibni yaratadi: dasturchi o'zgarishlarni tavsiflaydi, taqrizchilarni tayinlaydi, CI/CDni ishga tushiradi va o'zgarishlar qo'llanilishidan oldin fikr-mulohaza oladi. Bu GitLabning asosiy elementi, ammo GitHubdagi o'xshash mexanizm Pull Request (PR) deb ataladi.

GitLab Documentation, 2026 ma'lumotlariga ko'ra, GitLabda har yili 80 milliondan ortiq Merge Request yaratiladi. Har bir MR to'rtta asosiy komponentdan iborat: o'zgarishlar konteksti bilan tavsif (description), commitlar ro'yxati (commits), kod farqi (diff) va muhokama (discussion thread). Ushbu elementlardan biri bo'lmasa, MR to'liq emas deb hisoblanadi.

Merge Request (MR) uchta vazifani hal qiladi: himoyalangan filiallarda (main, develop) to'g'ridan-to'g'ri o'zgarishlarning oldini oladi, ko'rib chiqish orqali sifat nazoratini ta'minlaydi va kelajakdagi dasturchilar uchun muhokamalar tarixini saqlaydi. GitLabda MR holati interfeysda rang ko'rsatkichlari bilan aks etadi: kulrang — Draft, to'q sariq — kutish, yashil — Approved, binafsha — Merged va qizil — Closed.

Terminologiya: MR, PR va CR

Turli Git platformalarida Merge Request turlicha nomlanadi. GitLab “Merge Request” (MR), GitHub — “Pull Request” (PR) ishlatadi. O'xshashlik — Gerritdagi Change Request (CR). Uchalasi ham bir xil jarayonni bildiradi: kod ko'rib chiqish orqali o'zgarishlarni integratsiya qilish so'rovi. Termin tanlovi faqat loyihada ishlatiladigan platformaga bog'liq.

# O'zgarishlar bilan filial yaratish
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MRni GitLab/GitHub UI yoki CLI orqali yaratish mumkin:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: GitLab va GitHub o'rtasidagi farq nima

Merge Request GitLabda va Pull Request GitHubda — bular funksional jihatdan bir xil mexanizmlar, faqat nomlari farqli. Farq tarix bilan bog'liq: GitLab dastlab GitHubga Self-Hosted muqobil sifatida joylashgan va birlashtirish jarayoni uchun “Merge Request” terminini tanlagan. Oldin ishga tushirilgan GitHub esa “Pull Request” — o'zgarishlarni asosiy filialga “torish” (pull) so'rovidan foydalangan.

GitHub Docs, 2024 ma'lumotlariga ko'ra, ikkala vosita ham bir xil funksiyalar to'plamini qo'llab-quvvatlaydi: Markdown bilan tavsif, taqrizchilarni tayinlash, aniq kod qatorlariga sharh berish, tekshirish holatlari va shartlar bajarilganda avtomatik birlashtirish. Farqlar interfeys va qo'shimcha imkoniyatlar bilan bog'liq.

Merge Request qanday yaratiladi: bosqichma-bosqich ko'rsatma

Merge Request (MR) yaratish o'zgarishlar bilan filialni masofaviy omborga joylashtirish bilan boshlanadi. GitLab yoki GitHubga push qilgandan so'ng, interfeysda “Create Merge Request” yoki “Compare & Pull Request” tugmasi paydo bo'ladi. Dasturchi tavsifni to'ldiradi, maqsadli filialni (odatda develop yoki main) ko'rsatadi, taqrizchilarni tayinlaydi va teglar (labels) qo'shadi.

GitLab Documentation, 2025 ma'lumotlariga ko'ra, standart MR 72 belgigacha sarlavha, shablon (template) bilan tavsif va vazifaga (issue) havolani o'z ichiga oladi. Tavsif savollarga javob berishi kerak: nima qilindi, nima uchun, qanday test qilindi. GitLab Closes, Fixes, Resolves kalit so'zlari orqali birlashtirishda issuelarni avtomatik yopishni qo'llab-quvvatlaydi.

# .gitlab/merge_request_templates/default.md shablon namunasi
## What does this MR do?

[O'zgarishlarning qisqacha tavsifi: nima va nima uchun]

## How to test

1. Ishga tushirish ./gradlew test
2. Tekshirish LoginActivity test tokeni bilan
3. regressiya yo'qligini tekshirish AuthManager

## Related issues

Closes #142

MR ning hayot aylanishi: Draftdan Mergedgacha

Merge Request (MR) GitLabda beshta holatdan o'tadi. Birinchisi — Draft (qoralama), sarlavhada “Draft:” prefiksi bilan belgilanadi va birlashtirishni bloklaydi. Tayyor bo'lgach, dasturchi Draftni olib tashlaydi va MR Opened holatiga o'tadi — kod ko'rib chiqish boshlanadi va CI/CD pipeline ishga tushadi.

GitLab Docs, 2024 ma'lumotlariga ko'ra, Opened holatida taqrizchilar difni ko'rib chiqadilar, sharhlar qoldiradilar va Resolve Threads orqali o'zgarishlarni talab qiladilar. Barcha mavzular yopilganda va CI/CD muvaffaqiyatli o'tganda, mas'ul dasturchi Approve qo'yadi. Shundan so'ng MR Merge tugmasi bilan birlashtirilishi yoki avtomatik birlashtirishni (Auto-merge) kutishi mumkin.

GitLab uchta yakuniy holat variantini qo'llab-quvvatlaydi: Merged (muvaffaqiyatli birlashtirilgan), Closed (birlashtirilmasdan yopilgan, masalan, funksiyadan voz kechilganda) va Reopened (yopilgandan so'ng qayta ochilgan). Har bir holat audit uchun Activity Timeline MRda qayd etiladi.

Avtomatik holatlar va tetikleyiciler

GitLab hodisalar yuz berganda Merge Request holatini avtomatik yangilaydi: yangi commitlar push qilinganda Approvals qayta o'rnatiladi, muvaffaqiyatli CI pipelineda holat Pipeline passed bo'ladi, xatolikda — Pipeline failed (birlashtirish bloklanadi). Auto-mergeni sozlash mumkin: MR muvaffaqiyatli CI va barcha talab qilingan tasdiqlar olingandan so'ng avtomatik birlashadi.

• Draft — qoralama, CI ishga tushadi, lekin birlashtirish bloklangan
• Opened — ko'rib chiqishga tayyor, taqrizchilar tayinlangan, pipeline faol
• Approved — kerakli miqdordagi tasdiqlar olingan
• Merged — o'zgarishlar maqsadli filialga birlashtirilgan
• Closed — birlashtirilmasdan yopilgan

Merge Requestda kod ko'rib chiqish qoidalari

Merge Request (MR)da kod ko'rib chiqish — tijorat loyihalarining aksariyatida majburiy bosqich. SmartBear, 2023 tadqiqotiga ko'ra, MR bilan kod ko'rib chiqish nuqsonlar sonini 30–60% kamaytiradi va yangi dasturchilarning moslashishini tezlashtiradi. Asosiy qoida — har bir MRni kamida bitta, yaxshisi ikkita, kod yozishda ishtirok etmagan dasturchi tekshiradi.

MR tekshiruvi beshta mezonni o'z ichiga oladi: mantiqiy to'g'rilik, kod uslubiga muvofiqlik, test bilan qoplanish, xavfsizlik va unumdorlik. GitLabda Required Approvals — birlashtirishdan oldin majburiy tasdiqlar sonini sozlash mumkin, masalan, main uchun 2, develop uchun 1 tasdiq.

MRda muhokama Threads — kodning aniq qatorlariga sharhlar shaklida olib boriladi. Har bir mavzu birlashtirishdan oldin resolved (yopilgan) bo'lishi kerak. Ko'rib chiqishni tezlashtirish uchun MR hajmini cheklash tavsiya etiladi: 200–400 qator o'zgarish. Google Research (2022) ma'lumotlariga ko'ra, 400 qatordan ortiq MR 30% kam samarali tekshiriladi.

Merge Requestda CI/CD pipeline

Merge Request (MR) yaratilganda CI/CD pipeline avtomatik ishga tushadi. GitLabda bu .gitlab-ci.yml fayli orqali, GitHubda — GitHub Actions workflow orqali amalga oshiriladi. Pipeline loyiha qurilishi (build), birlik testlarini (unit tests) ishga tushirish, linterlar (lint), statik tahlil (SAST) va kod qoplanishini tekshirishni o'z ichiga oladi.

GitLab Blog, 2024 ma'lumotlariga ko'ra, pipeline holati to'g'ridan-to'g'ri MRda ko'rsatiladi: yashil belgi (passed), qizil xoch (failed) yoki sariq doira (running). Pipeline muvaffaqiyatsiz bo'lsa, GitLab tuzatish kiritilgunga qadar Merge tugmasini bloklaydi. Sozlamalarda “Merge when pipeline succeeds” — muvaffaqiyatli pipelinedan so'ng avtomatik birlashtirishni yoqish mumkin.

# .gitlab-ci.yml — Android loyihasi uchun namuna
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Birlashtirish usullari: Squash, Merge Commit, Fast-Forward

GitLab va GitHub Merge Request uchun uchta birlashtirish usulini taklif qiladi. Tanlov jamoa siyosati va talab qilinadigan tarix tozaligiga bog'liq. Merge Commit — alohida birlashtirish commitini yaratadi, feature filialining butun tarixini saqlaydi. Squash — filialning barcha commitlarini maqsadli filialda bitta commitga birlashtiradi. Fast-Forward — commitlarni birlashtirish commitisiz chiziqli tarzda qo'llaydi.

GitLab Docs, 2025 ma'lumotlariga ko'ra, Squash yuqori commit zichligiga ega loyihalarda (bitta feature filialida 20+ commit) afzal ko'riladi. Fast-Forward Trunk-Based Development uchun majburiydir. Merge Commit Git Flowda filiallanish semantikasini saqlash uchun ishlatiladi.

• Merge Commit — tarixni saqlaydi, birlashtirish commitini yaratadi, Git Flow uchun mos
• Squash — barcha commitlarni bittaga birlashtiradi, toza tarix, oraliq commitlar yo'qoladi
• Fast-Forward — birlashtirish commitisiz chiziqli tarix, TBDda majburiy

Eng yaxshi amaliyotlar: yaxshi MRni qanday yozish

Sifatli Merge Request (MR) ko'rib chiqish vaqtini qisqartiradi va xatolar sonini kamaytiradi. Birinchi qoida — bitta MR bitta vazifani hal qiladi. Agar o'zgarishlar bir nechta bog'liq bo'lmagan funksiyalarga ta'sir qilsa, ularni alohida MRlarga bo'lish kerak. Ikkinchisi — MR sarlavhasi ma'lumot beruvchi bo'lishi kerak: “Fix stuff” yoki “Update code” o'rniga “Add OAuth2 authentication with Google provider”.

Google Engineering Practices, 2024 ma'lumotlariga ko'ra, yaxshi MR kontekst tavsifini o'z ichiga oladi: nima uchun o'zgarishlar kerak, ular qanday test qilingan, qanday xavflar bor. MR hajmi 400 qator o'zgarishdan oshmasligi kerak. Agar hajm kattaroq bo'lsa — vazifa kichik vazifalarga bo'linishi kerak. Hujjatlar va testlar uchun istisnolar ruxsat etiladi, ammo tushuntirish bilan.

Merge Request (MR) yangi funksionallik uchun avtomatik testlarni o'z ichiga olishi kerak. GitLabda Coverage Check siyosatini sozlash mumkin — kod qoplanishi chegaradan (masalan, 80%) pastga tushsa, MR avtomatik bloklanadi. Bu yangi funksionallik loyihaning umumiy sifatini pasaytirmasligini kafolatlaydi.

• Bitta MR — bitta vazifa: katta o'zgarishlarni bir nechta kichik MRlarga bo'ling
• Shablon bilan tavsif: bir xillik uchun .gitlab/merge_request_templates dan foydalaning
• Hajm 400 qatorgacha: katta MRlar sekinroq va ko'proq xatolar bilan tekshiriladi
• Testlar majburiy: yangi funksiyalar birlik testlari bilan qoplanishi kerak

MR tavsif shablonlari

GitLab Merge Request shablonlarini .gitlab/merge_request_templates/ fayllari orqali qo'llab-quvvatlaydi. Shablon bo'limlarni o'z ichiga oladi: nima qilindi, qanday test qilish, bog'liq vazifalar va tekshirish ro'yxati. Shablonlardan foydalanish MR yaratishni tezlashtiradi va dasturchilarning muhim ma'lumotlarni ko'rsatishni unutmasligini kafolatlaydi. MR tavsifida birlashtirishda vazifalarni avtomatik yopish uchun bog'liq issue (Closes #N) majburiy ko'rsatiladi.