Pull Request: bu nima, yaratilish jarayoni va kod ko'rib chiqish

Pull Request nima?

Pull Request (PR) — bu taqsimlangan versiyalarni boshqarish tizimi doirasida bir filialdan ikkinchisiga o‘zgarishlarni kiritish uchun rasmiy so‘rovdir. PR GitHub, GitLab va Bitbucket platformalarida hamkorlikda ishlab chiqishning markaziy elementi bo‘lib, kod muhokamasi, avtomatik testlash va o‘zgarishlarni tasdiqlash jarayonini birlashtiradi.

“Pull Request” nomi operatsiyaning mohiyatini aks ettiradi: dasturchi depozitariy egasidan o‘zgarishlarini “olishni” (pull) so‘raydi (request). Bu atama 2008 yilda GitHub tomonidan kiritilgan — bundan oldin shunga o‘xshash mexanizm yamalar va merge request (GitLab atamasi) shaklida mavjud edi. Bugungi kunda PR Git bilan jamoada ishlash uchun de fakto standartdir.

GitHub Octoverse, 2025 ma’lumotlariga ko‘ra, ochiq manbali loyihalarning 89% o‘zgarishlar kiritish uchun PR yaratishni talab qiladi. Korporativ ishlanmada bu ko‘rsatkich 95% ga etadi. PR nafaqat texnik vosita, balki ishlab chiqish madaniyatining bir qismiga aylandi: PR orqali bilim almashinuvi, xatolarni aniqlash va arxitektura qarorlarini muvofiqlashtirish amalga oshiriladi.

Pull Request tarkibiy qismlari

Oddiy PR sarlavha, tavsif, o‘zgartirilgan fayllar ro‘yxati (diff), sharhlovchilarning izohlari va CI tekshiruvlari holatidan iborat. Har bir PR ma’lum bir manba va maqsadli filialga bog‘langan bo‘lib, birlashtirilgandan so‘ng avtomatik ravishda o‘chirilishi mumkin.

Pull Request qanday yaratiladi

PR yaratish feature filialini masofaviy depozitariyada nashr qilish bilan boshlanadi. Pushdan so‘ng, dasturchi platforma interfeysi yoki CLI (gh, glab) orqali PR ochadi. Jarayonni GitHub misolida ko‘rib chiqamiz.

Filialni push qilish va PR ochish

Birinchi qadam — feature filialini masofaviy depozitariyaga push qilib, veb-interfeys yoki buyruq satri orqali Pull Request yaratish.

# Feature filialini yarating va push qiling
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLI orqali PR yarating
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

PR yaratilgandan so‘ng, GitHub avtomatik ravishda CI quvurlarini (GitHub Actions) ishga tushiradi, maqsadli filial bilan ziddiyatlarni tekshiradi va sharhlovchilarni taklif qiladi. PR tavsifi shabloni .github/PULL_REQUEST_TEMPLATE.md orqali sozlanishi mumkin, shunda barcha PRlar majburiy bo‘limlarni o‘z ichiga oladi: maqsad, o‘zgarishlar, testlash, bog‘liq vazifalar.

Tavsif va teg qo‘yish

Sifatli PR tavsifi o‘z ichiga oladi: vazifaga havola (issue/ticket), o‘zgarishlarning qisqa tavsifi, testlash bo‘yicha ko‘rsatma va bog‘liq o‘zgarishlar ro‘yxati. Yorliqlar (bug, feature, refactoring) PRlarni toifalarga ajratishga yordam beradi, tayinlangan shaxslar va sharhlovchilar esa CODEOWNERS orqali avtomatik tayinlanadi.

# CODEOWNERS orqali sharhlovchilarni tayinlang (depozitariy ildizidagi fayl)
# Misol .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Gh cli orqali sharhlovchilar tayinlangan holda PR yarating
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — o‘zgartirilgan fayllarga qarab sharhlovchilarni avtomatik tayinlash uchun GitHub/GitLabning standart mexanizmi. Masalan, src/auth/ katalogidagi har qanday o‘zgarish avtomatik ravishda team-auth va senior-dev ni sharhlovchi sifatida tayinlaydi. Bu jarayonni tezlashtiradi va tegishli odamlarning PRni ko‘rishini kafolatlaydi.

Ko‘rib chiqishdan keyin PRni yangilash

Sharhlovchining izohlarini olgandan so‘ng, dasturchi o‘sha feature filialida tuzatishlar kiritadi va yangi commitlarni push qiladi — PR avtomatik ravishda yangilanadi. Agar PR allaqachon ochiq bo‘lsa, nashr qilingan feature filialida tarixni (rebase) qayta yozmaslik muhim, chunki bu izohlardagi aniq commitlarga havolalarni buzadi.

# Sharhlovchining izohlariga ko‘ra o‘zgarishlar kiriting
git checkout feature/biometric-auth
# kodni tuzating
git commit -m "fix: handle biometric timeout per review"
git push

# PR avtomatik yangilanadi
# Tasdiqlashdan so‘ng — PRni GitHub interfeysi orqali birlashtiring

Kod ko‘rib chiqish jarayoni

Kod ko‘rib chiqish — Pull Requestning markaziy elementi. Sharhlovchi o‘zgarishlarni to‘g‘rilik, kod uslubi, xavfsizlik va arxitektura muvofiqligi nuqtai nazaridan tekshiradi. Sifatli ko‘rib chiqish nafaqat xatolarning oldini oladi, balki jamoa ichida kod bazasi haqidagi bilimlarni tarqatadi.

Google Engineering Practices (2025) quyidagi kod ko‘rib chiqish tamoyillarini tavsiya qiladi: sharhlovchi o‘zgarishlar kontekstini tushunishi, umumiy mulohazalar o‘rniga aniq tavsiyalar berishi, texnik va stilistik izohlarni ajratishi kerak. Ko‘rib chiqish vaqti PR yaratilgan paytdan boshlab 24 soatdan oshmasligi kerak.

Mobil ilovalarni ishlab chiqish uchun kod ko‘rib chiqish maxsus tekshiruvlarni o‘z ichiga oladi: targetSdk bilan moslik, lifecycle (Android) / view lifecycle (iOS) ni to‘g‘ri boshqarish, xotira oqishlarining yo‘qligi (LeakCanary, Instruments), qorong‘u rejim va lokalizatsiyani qo‘llab-quvvatlash. Bu tekshiruvlar linterlar va Detekt/ktlint orqali avtomatlashtirilishi mumkin.

Izoh turlari

PR platformalari uch turdagi izohlarni qo‘llab-quvvatlaydi: umumiy (butun PRga), qatorli (kodning aniq qatoriga) va takliflar (almashtiriladigan kod bilan suggestions). Takliflar o‘zgarishni bir marta bosish bilan qo‘llash imkonini beradi, bu jarayonni tezlashtiradi va iteratsiyalar sonini kamaytiradi.

Barcha izohlar hal qilinganidan va CI tekshiruvlari o‘tgandan so‘ng, sharhlovchi tasdiqlash (Approved) yuboradi. PR birlashtirilishi mumkin. GitHub va GitLab filial himoyasi qoidalarini (branch protection rules) qo‘llab-quvvatlaydi: majburiy tasdiqlashlar soni, majburiy CI tekshiruvlari, PRsiz main ga push qilishni taqiqlash. Mobil loyihalar uchun branch protection shuningdek build tekshiruvini ham o‘z ichiga oladi: agar ilova qurilmasa PR birlashtirilmaydi (gradle build failed / xcodebuild failed).

PRdagi ziddiyatlarni hal qilish

Merge ziddiyatlari Pull Requestda faol jamoa ishida odatiy holatdir. Platformalar oddiy ziddiyatlar uchun veb-interfeys orqali yechim taklif qiladi yoki mahalliy hal qilishni tavsiya qiladi. GitHub Actions har bir pushda feature filialining birlashtirish imkoniyatini avtomatik tekshiradi va agar birlashtirish imkoni bo‘lmasa, PRni conflict deb belgilaydi.

Pull Request uchun eng yaxshi amaliyotlar

Samarali Pull Requestlar kod ko‘rib chiqishni tezlashtiradi va xatolar sonini kamaytiradi. SmartBear (2025) tadqiqoti shuni ko‘rsatdiki, 200 qatorgacha kodga ega PRlar 1000 qatordan ortiq PRlarga qaraganda 2 baravar ko‘proq mazmunli izoh oladi va ko‘rib chiqish vaqti 3 baravar qisqaradi.

• Kichik PRlar — optimal hajm 100-300 qator. Katta PRlarni mantiqiy qismlarga bo‘ling: har bir PR bitta vazifani hal qiladi. Bu ko‘rib chiqishni soddalashtiradi va ziddiyatlar ehtimolini kamaytiradi
• Tushunarli tavsif — sarlavha Conventional Commitsga mos (feat:, fix:, refactor:), PR mazmuni “nima va nega” ni o‘z ichiga oladi, “qanday” ni emas (kod o‘zi uchun gapiradi). Shablon: maqsad → o‘zgarishlar → testlash → bog‘liq masalalar
• Tez qayta aloqa — 24 soat ichida ko‘rib chiqish. Agar PR bir kundan ortiq kutsa — jamoa kontekstni yo‘qotadi, merge paytida ziddiyatlar soni ortadi
• Avtomatlashtirish — linterlar, formatlagichlar va testlar PR yaratilganda avtomatik ishga tushishi kerak. Qizil CI tekshiruvlari bo‘lgan PRni birlashtirishga yo‘l qo‘ymang
• Draft PR — arxitektura haqida erta muhokama qilish uchun foydalaning. Draft PR ko‘rib chiqishni talab qilmaydi va birlashtirilmaydi, ammo kodni erta bosqichda hamkasblarga ko‘rsatishga imkon beradi

Qo‘shimcha amaliyotlar: juma kuni kechqurun PR yaratmang (hech kim dushanbagacha ko‘rib chiqmaydi), 1-2 kishidan ko‘rib chiqish so‘rang (ko‘pi jarayonni sekinlashtiradi, sifatni oshirmaydi), birlashtirishdan oldin tarixni siqish uchun squash merge dan foydalaning. Mobil loyihalar uchun PR tavsifiga test build havolasini (Firebase App Distribution / TestFlight) qo‘shish tavsiya etiladi, shunda sharhlovchi o‘zgarishlarni ishlaydigan ilovada tekshirishi mumkin.

Turli platformalarda Pull Request

Pull Request bilan ishlash uchun asosiy platformalar — GitHub, GitLab va Bitbucket. Umumiy kontseptsiyaga qaramay, har birining jamoa uchun vositani tanlashda e’tiborga olinadigan xususiyatlari bor.

GitHub — eng katta hamjamiyatga ega eng mashhur platforma, CI/CD uchun Actions va keng ilovalar ekotizimi (GitHub Marketplace). GitLab o‘rnatilgan CI/CD va to‘liq self-hosted joylashtirish imkoniyati bilan ajralib turadi. Bitbucket Jira va Atlassian ekotizimi bilan chambarchas integratsiyalashgan, korporativ muhitda mashhur.

Mobil ilovalarni ishlab chiqish uchun platforma tanlovi ko‘pincha CI/CD imkoniyatlari bilan belgilanadi: GitHub Actions iOS qurish uchun macOS runnerlarni qo‘llab-quvvatlaydi, GitLab iOS/Android uchun o‘rnatilgan runnerlarga ega, Bitbucket Firebase Test Lab bilan yaxshi integratsiyalashadi. Platformadan qat’i nazar, PR jarayoni bir xil: filial → ko‘rib chiqish → CI → merge.