Apruv qilish / Tasdiqlash: bu nima, approval va code review Gitda

Pull request apruvi nima

Apruv (approval) — bu pull request uchun ijobiy taqriz, ya‘ni ko‘rib chiqruvchi kodni tekshirdi, muhim muammolar topmadi va o‘zgarishlarni birlashtirishga tayyor deb hisoblaydi. GitHub interfeysida bu PR sahifasidagi yashil «Approve» tugmasidir. Apruvdan keyin muallif (yoki yozish huquqiga ega har qanday ishtirokchi) merge qilishi mumkin.

Apruv jarayoni Branch Protection Rules ning bir qismidir. Repozitoriya egalari majburiy talablarni sozlaydi: minimal apruv soni (masalan, 1 yoki 2), kim apruv qilishi mumkin (kod egalari, jamoa a’zolari) va PR o‘zgarishlardan keyin qayta apruv qilinishi kerakmi (Dismiss stale reviews). Qoidalar sozlanmagan holda, apruv ixtiyoriy qadamdir, ammo professional jamoalarda majburiydir.

GitLab Approval Rules nomli o‘xshash mexanizmdan foydalanadi. GitLabda turli guruhlardan (masalan, backend dasturchilaridan 2 ta va DevOpsdan 1 ta) qancha apruv talab qilinishini sozlash mumkin. Barcha majburiy apruvlar olingandan so‘ng, PR yashil CI/CD pipeline sharti bilan avtomatik ravishda merge uchun blokdan chiqariladi.

Ko'rib chiqish turlari: Approve, Request Changes, Comment

GitHub va GitLabda ko‘rib chiqruvchi pull requestda qoldirishi mumkin bo‘lgan uch turdagi ko‘rib chiqish mavjud. Har bir tur birlashtirish jarayoni uchun turli holat va oqibatlarga ega. Approve — yashil, Request Changes — qizil, Comment — neytral kulrang. Turni tanlash kod sifati va o‘zgarishlarning qabul qilishga tayyorligiga bog‘liq.

Approve — ko‘rib chiqruvchi tasdiqlaydi: kod to‘g‘ri yozilgan, standartlarga mos, aniq xatolar yo‘q va birlashtirilishi mumkin. Approve kod ideal degani emas — faqat ishlab chiqarish uchun yetarlicha yaxshi. Kichik izohlar (uslub, nomlash) bo‘lsa, ularni PRni bloklamasdan sharh sifatida qoldirish mumkin.

Request Changes — ko‘rib chiqruvchi merge dan oldin tuzatilishi kerak bo‘lgan muammolarni topadi: mantiqiy xatolar, zaifliklar, arxitektura buzilishlari, testlarning yo‘qligi. Request Changes dan keyin PR bloklanadi va blokdan chiqish uchun o‘sha ko‘rib chiqruvchidan qayta apruv talab qilinadi (agar yangi commitlarda Dismiss stale reviews opsiyasi yoqilgan bo‘lsa).

• Approve — kod birlashtirishga tayyor, CI o‘tgandan keyin merge qilish mumkin.
• Request Changes — majburiy tuzatishlar, PR qayta ko‘rib chiqilgunga qadar bloklangan.
• Comment — PRni bloklamasdan umumiy izoh yoki taklif.

Repozitoriyada apruv qoidalarini sozlash

Branch Protection Rules — bu GitHubda birlashtirish sifatini nazorat qilish mexanizmi. Har bir himoyalangan filial (main, develop, release/*) uchun Settings → Branches da sozlanadi. Asosiy parametrlar: majburiy apruvlar soni, kod egalari (CODEOWNERS), majburiy CI/CD tekshiruvi va PRsiz push ta’qiqi.

Dismiss stale pull request approvals parametri — PRga yangi commit qo‘shilsa, apruvlarni avtomatik bekor qiladi. Bu ko‘rib chiqruvchilar aynan birlashtiriladigan kod versiyasini apruv qilishini kafolatlaydi. Bu sozlamasiz, muallif apruvdan keyin yangi kod qo‘shishi mumkin va u qayta tekshirilmasdan main ga tushadi.

CODEOWNERS — repozitoriyaning ildizidagi turli kataloglar uchun mas’ullarni tayinlaydigan fayl. PR kod egasiga tegishli fayllarga tegilsa, uning apruvi majburiy bo‘ladi. CODEOWNERS mas’uliyat zonalarini taqsimlaydi: iOS dasturchisi Swift fayllari uchun, DevOps — Docker konfiguratsiyalari uchun, testerlar — test stsenariylari uchun javob beradi.

# Repo ildizida namunaviy CODEOWNERS fayli

# iOS dasturchilari Swift kodiga egalik qiladi
*.swift @team/ios-developers

# DevOps CI/CD konfiguratsiyasiga egalik qiladi
.github/workflows/* @devops-team

# QA muhandislari testlarni ko'rib chiqadi
**/tests/* @qa-engineers

# Qolgan hamma narsa uchun standart egalar
* @tech-leads

Apruvdan oldin code review: nimani tekshirish

Code review apruvdan oldin — bu diffga yuzaki qarash emas, balki kodni tizimli tekshirishdir. Sifatli code review arxitektura, mantiq, uslub, testlar va xavfsizlikni tekshirishni o‘z ichiga oladi. Bu tekshiruvsiz, apruv rasmiyatchilikka aylanadi va sifat nazorat vositasi bo‘lmaydi.

Avval nimani tekshirish kerak: o‘zgarishlar mantig‘i — kod qo‘yilgan vazifani hal qiladimi, nojo‘ya ta’sirlar bormi, chekka holatlarni qayta ishlash to‘g‘rimi. Testlar — yangi testlar barcha stsenariylarni qamrab oladimi, mavjud testlar o‘zgarishlardan keyin o‘tadimi. Xavfsizlik — SQL inyeksiyalari, XSS, nozik ma’lumotlarning sizib chiqishi bormi.

Ko‘rib chiqish predmeti bo‘lmasligi kerak: formatlash uslubi (buning uchun linterlar va formatterlar bor), oldindan qabul qilingan arxitektura qarorlari (ular kod yozishdan oldin muhokama qilinadi). Agar ko‘rib chiqishda 400 qatordan ortiq bo‘lsa yoki bir soatdan ko‘proq davom etsa — bu vazifa juda katta va parchalanishi kerakligining signalidir. Ko‘rib chiqish uchun eng yaxshi amaliyot — PR yaratilganidan keyin 24 soat ichida 200–400 qatorlik qismlar.

• Mantiq — vazifa yechimining to‘g‘riligi, xato boshqaruvi, chekka holatlar.
• Testlar — yangi stsenariylarning qamrovi, mavjudlarining o‘tishi, flaky-testlarning yo‘qligi.
• Xavfsizlik — inyeksiyalarning yo‘qligi, chiqishni ekranlash, ma’lumotlarga kirish.
• Unumdorlik — algoritmlarning samaradorligi, ortiqcha so‘rovlar, xotira sizmalari.
• Hujjatlar — hujjatlar yangilanganmi, murakkab qismlardagi sharhlar tushunarlimi.

Jamoada apruv bilan ish oqimi

5–10 dasturchidan iborat jamoada apruv bilan odatdagi ish oqimi quyidagicha: dasturchi PR yaratadi, ko‘rib chiqruvchilarni tayinlaydi (odatda jamoadan 1–2 kishi yoki kod egalari), CI/CD avtomatik tekshirishlarni ishga tushiradi. Barcha majburiy apruvlar va yashil CI olingandan so‘ng, muallif merge qiladi. PR yaratilishidan mergegacha bo‘lgan vaqt murakkablikka qarab o‘rtacha 2 soatdan 2 kungacha.

GitHub Actions apruvdan keyin merge-ni avtomatlashtirishga imkon beradi. Filial qoidalari sozlangan bo‘lsa, GitHub barcha shartlar bajarilgunga qadar merge-ni o‘zi bloklaydi. Ba’zi jamoalar bors-ng yoki Mergify — barcha apruvlarni olib CI o‘tgandan keyin PRni avtomatik birlashtiradigan botlardan foydalanadi. Bu jarayonni tezlashtiradi va merge paytida inson omilini yo‘q qiladi.

Zamonaviy yondashuv — qisqa muddatli filiallar bilan trunk-based development. Bu ish oqimida apruv bir necha soat ichida olinishi kerak, aks holda vazifa eskirgan hisoblanadi va main bilan qayta sinxronizatsiyani talab qiladi. Yuqori ko‘rib chiqish madaniyatiga ega jamoalar apruv vaqtini 4 ish soatidan oshmasligiga intiladi.

Apruvdagi xatolar va ulardan qanday qochish

Eng keng tarqalgan xato — kodni haqiqiy tekshirmasdan rasmiy apruv. PR katta bo‘lsa yoki muddat yaqin bo‘lsa, ko‘rib chiqruvchi o‘zgarishlarga kirmasdan Approve tugmasini bosishi mumkin. Bu butun code review jarayonini qadrsizlantiradi. Yechim: PR hajmiga cheklov qo‘yish (400 qatordan oshmasligi) va avtomatik tekshirish uchun kod tahlil vositalaridan (SonarQube, CodeClimate) foydalanish.

Ikkinchi xato — haddan tashqari qattiq apruv. Ideal kodni kutish rivojlanishni bloklaydi. Ko‘rib chiqruvchilar ba’zan sifatga ta’sir qilmaydigan uslubiy izohlarni tuzatishni talab qiladi. Yechim: majburiy izohlarni (bloklovchi) va ixtiyoriy takliflarni (sharhlar) aniq ajratish. GitHub izohning bloklovchi yoki yo‘qligini aniq ko‘rsatishga imkon beradi.

Uchinchi xato — CI/CD ni tekshirmasdan apruv. Kod to‘g‘ri ko‘rinsa ham, u kompilyatsiya qilinmasligi yoki testlarda muvaffaqiyatsiz bo‘lishi mumkin. Sozlangan Branch Protection qizil CI vaqtida merge-ni avtomatik bloklaydi, ammo ba’zi jamoalar tezlik uchun bu himoyani o‘chiradi. Yechim: apruvdan oldin har doim CI holatini tekshiring va qizil pipeline bilan PRni hech qachon ma’qullamang.

• Rasmiy apruv — kodni real tekshirmaslik. Yechim: PRga 400 qator cheklovi.
• Haddan tashqari qattiqqo‘llik — uslubiy izohlarga ko‘ra bloklash. Yechim: blocking va optionalga bo‘lish.
• CIni e’tiborsiz qoldirish — qizil pipeline bilan apruv. Yechim: har doim tekshiruv holatini tekshiring.
• Muallifni tayinlash — PR muallifidan apruv. Yechim: muallifga qarshi Branch Protection sozlash.