Pull Request — nima, qanday ochiladi, code review jarayoni

~20 daq · Git · GitHub bilan ishlash

Muammodan boshlaylik

Jamoada 6 dasturchi. Har biri o'z kodini to'g'ridan-to'g'ri main ga push qiladi. Natija:

  • Yangi dasturchi bazani o'chirib yuboradigan migratsiya push qildi — hech kim ko'rmadi
  • Ikki kishi bir xil funksiyani turlicha yozdi
  • Testlar buzildi — kimning commit i sabab, noma'lum
  • "Bu kod nima uchun bunday yozilgan?" — so'raydigan odam yo'q

Kerak — kod main ga tushishidan oldin uni ko'rib chiqish, muhokama qilish va testlash jarayoni. Bu — Pull Request (PR).

Pull Request nima?

Pull Request — "mening branch imdagi o'zgarishlarni main ga qo'shishingizni so'rayman" degan taklif. GitHub da bu sahifa:

  • Tavsif — nima va nima uchun
  • Files changed — barcha o'zgarishlarning diff i (10-dars)
  • Izohlar — har bir qatorga muhokama
  • Review — jamoa a'zolarining tasdig'i yoki o'zgartirish so'rovi
  • Checks — avtomatik testlar natijasi (GitHub Actions, 38-dars)
  • Merge tugmasi — hammasi tayyor bo'lganda

[!INFO] GitLab da xuddi shu narsa Merge Request (MR) deb ataladi. Nom farq qiladi — g'oya bir xil.

PR ochish — to'liq jarayon

1. Branch va commitlar

git switch main && git pull
git switch -c feature/mahsulot-qidiruvi
# ... ishlash, commitlar ...
git push -u origin feature/mahsulot-qidiruvi

remote: Create a pull request for 'feature/mahsulot-qidiruvi' on GitHub by visiting:
remote:      https://github.com/otabek/dokon/pull/new/feature/mahsulot-qidiruvi

2. GitHub da PR yaratish

Havolani oching (yoki repozitoriy sahifasida sariq "Compare & pull request" tugmasi):

  • base: main ← compare: feature/mahsulot-qidiruvi
  • Sarlavha va tavsif yozing
  • O'ng panelda: Reviewers (kim ko'rib chiqadi), Assignees, Labels
  • Create pull request

Yoki terminaldan (54-dars):

gh pr create --title "Mahsulot qidiruvi" --body "..." --reviewer malika

Draft PR

Ish tugamagan, lekin erta fikr kerak — Create draft pull request. Draft PR ni merge qilib bo'lmaydi, reviewerlar bezovta qilinmaydi. Tayyor bo'lganda — "Ready for review".

Yaxshi PR tavsifi

## Nima

Mahsulotlar sahifasiga nom va kategoriya bo'yicha qidiruv qo'shildi.

## Nima uchun

Foydalanuvchilar 2000+ mahsulot orasidan kerakligini topa olmayotgan edi (#87).

## Qanday

- Backend: `GET /api/mahsulotlar?q=...&kategoriya=...` — MySQL FULLTEXT indeks bilan
- Frontend: debounce (300ms) bilan qidiruv maydoni
- Bo'sh natija uchun "Hech narsa topilmadi" holati

## Qanday tekshirish

1. `npm run dev`
2. /mahsulotlar sahifasida "noutbuk" deb yozing
3. Kategoriya filtrini tanlang

## Skrinshot

(rasm)

Closes #87

Closes #87 — PR merge qilinganda 87-issue avtomatik yopiladi (25-dars).

[!TIP] Ko'p repozitoriylarda .github/pull_request_template.md fayli bor — yangi PR ochilganda tavsif maydoni avtomatik shu shablon bilan to'ldiriladi. O'z loyihangizga ham qo'shing.

Yaxshi PR — kichik PR

PR hajmi Review sifati
50 qator Har bir qator diqqat bilan o'qiladi, xatolar topiladi
500 qator Yuzaki ko'rib chiqiladi
3000 qator "LGTM 👍" — hech kim o'qimaydi

Qoidalar:

  • Bitta PR — bitta maqsad. Funksiya + refaktoring + formatlash — uchta PR
  • 400 qatordan kam — ideal
  • Katta vazifani bosqichlarga bo'ling: avval model, keyin API, keyin UI

Code review — ko'rib chiqish

Reviewer sifatida

Files changed tabida:

  • Qatorga sichqonchani olib boring → + → izoh
  • Bir nechta qatorni belgilash mumkin
  • Suggestion — aniq tuzatish taklifi (muallif bir tugma bilan qabul qiladi):
```suggestion
const narx = Math.round(mahsulot.narx * 100) / 100;
```

Oxirida — Review changes:

  • Comment — umumiy fikr, qaror yo'q
  • Approve ✅ — tasdiqlash
  • Request changes ❌ — merge dan oldin tuzatish kerak

Nimaga qarash kerak

  1. To'g'rilik — kod vazifani bajaradimi? Chekka holatlar (bo'sh ro'yxat, null, juda katta son)?
  2. Xavfsizlik — SQL injection, sirlar kodda, ruxsat tekshiruvi
  3. Tushunarlilik — 6 oydan keyin kimdir buni tushunadimi?
  4. Testlar — yangi kod testlanganmi?
  5. Loyiha uslubi — mavjud yondashuvlarga mosmi?

Yaxshi izoh yozish

❌ ✅
"Bu noto'g'ri" "mahsulotlar bo'sh bo'lsa, bu yerda undefined.length xatosi chiqmaydimi?"
"Nega bunday qilding?" "Bu yerda map o'rniga for tanlanganining sababi bormi? map qisqaroq bo'lardi"
(formatlash haqida 20 ta izoh) Prettier ni CI ga qo'shish — mashina tekshirsin

Kod haqida gapiring, odam haqida emas. Savollar — buyruqlardan yaxshiroq. Kichik narsalarni nit: bilan belgilang ("nit: o'zgaruvchi nomi x emas, soni bo'lsa yaxshiroq") — bu "majburiy emas" degani.

Muallif sifatida

  • Har bir izohga javob bering: tuzatdingiz — "Tuzatildi ✅" yoki rozi emassiz — sababini tushuntiring
  • Tuzatishlarni yangi commitlar bilan push qiling — PR avtomatik yangilanadi
  • Review ni shaxsiy qabul qilmang — u kodni yaxshilaydi, sizni baholamaydi

Merge qilish

Barcha tasdiqlar olindi, testlar yashil — Merge pull request. Uch variant (15, 17-darslar):

Variant Natija main da Qachon
Create a merge commit Barcha commitlar + merge commit Tarix to'liq saqlansin
Squash and merge Bitta commit Ko'p "fix typo" li PR lar — eng ommabop
Rebase and merge Barcha commitlar, to'g'ri chiziqda Commitlar allaqachon toza

Merge dan keyin — Delete branch tugmasi. Lokalda:

git switch main
git pull
git branch -d feature/mahsulot-qidiruvi

Branch protection — main ni himoyalash

Repozitoriy → Settings → Branches (yoki Rules) → main uchun qoida:

  • ✅ Require a pull request before merging — to'g'ridan-to'g'ri push taqiqlangan
  • ✅ Require approvals: 1 — kamida bitta tasdiq
  • ✅ Require status checks to pass — testlar o'tishi shart (38-dars)
  • ✅ Require conversation resolution — barcha izohlar hal qilingan
  • ✅ Block force pushes

Endi hech kim — hatto administrator ham (sozlamaga qarab) — main ni tasodifan buza olmaydi.

Nima uchun shunday?

Nima uchun code review shunchalik muhim — tajribali dasturchilar kodini ham tekshirish kerakmi?

Ha — chunki review faqat xatolarni topish uchun emas. Birinchidan, ikkinchi ko'z: muallif o'z kodidagi xatolarni ko'rmaydi — u nima yozmoqchi bo'lganini "o'qiydi", nima yozganini emas. Ikkinchidan, bilim tarqalishi: review qilgan odam endi bu kodni biladi — muallif ta'tilga ketsa yoki ishdan ketsa, loyiha to'xtamaydi. Uchinchidan, o'rganish: yangi dasturchilar tajribalilarning izohlaridan, tajribalilar esa yangi yondashuvlardan o'rganadi. Va nihoyat, hujjat: PR — "nima uchun bu kod shunday" degan savolga yillar o'tib ham javob beradigan muhokama arxivi.

Xulosa

Eslab qoling:

  • PR — branch ni main ga qo'shish taklifi: diff, muhokama, review, testlar
  • Jarayon: branch → commitlar → push -u → PR → review → merge → branch o'chirish
  • Tavsif: nima, nima uchun, qanday tekshirish; Closes #N
  • Kichik PR (< 400 qator) — yaxshi review
  • Draft PR — erta fikr uchun
  • Review: Comment / Approve / Request changes; suggestion bloklari
  • Izohlar — kod haqida, savol shaklida; nit: — kichik narsalar
  • Merge: merge commit / squash / rebase
  • Branch protection — main ni himoyalash

Keyingi dars

24-dars: Fork — nima, qachon kerak, fork workflow