Pull Request va kod tekshiruvi - Git va GitHub

Pull Request (PR) - jamoaviy ishlashning markazi. Bu "mening o'zgarishlarimni ko'rib chiqing va qabul qiling" degan rasmiy so'rov.

Ish oqimi #

PR - kod sifatini nazorat qilishning asosiy vositasi

PR yaratish #

Terminal

git switch -c feature/hisobot
# ... ishlash va kommit qilish ...
git push -u origin feature/hisobot

Natija

remote: Create a pull request for 'feature/hisobot' on GitHub by visiting:
remote:      https://github.com/husanboy/loyiha/pull/new/feature/hisobot

Havolani oching yoki GitHub saytida Compare & pull request tugmasini bosing.

CLI orqali:

Terminal

gh pr create --title "Oylik hisobot sahifasi" --body "Fixes #42"

# Interaktiv rejimda
gh pr create

Yaxshi PR tavsifi #

MARKDOWN

## Nima qilindi

Admin panelga oylik savdo hisoboti sahifasi qo'shildi.

## Nima uchun

Mijoz har oy hisobotni qo'lda tayyorlashga majbur edi.
Bu vazifa 3 soat vaqt olardi.

## Qanday tekshirish

1. Admin panelga kiring
2. "Hisobotlar" bo'limiga o'ting
3. Oy va yilni tanlang
4. "Yuklab olish" tugmasini bosing

## Ekran surati

![Hisobot sahifasi](https://.../rasm.png)

## Eslatmalar

- `hisobotlar` jadvali uchun migratsiya qo'shildi
- PDF yaratish uchun yangi bog'liqlik qo'shilmadi, HTML dan foydalanildi

Fixes #42

PR ni kichik qiling

PR hajmi	Tekshiruv sifati
50 satrgacha	Har bir satr diqqat bilan o'qiladi
200-400 satr	Asosiy joylar ko'riladi
1000+ satr	"LGTM" deb tasdiqlanadi, hech nima o'qilmaydi

Katta o'zgarishni bir necha PR ga bo'ling. Bu tekshiruvchiga hurmat.

Kod tekshiruvi #

Tekshiruvchi sifatida #

Nimaga e'tibor berish kerak?

Kod nima qilyapti? - avval tushunib oling
Xatolik holatlari - null, bo'sh massiv, katta son
Xavfsizlik - SQL inyeksiya, XSS, huquq tekshiruvi
Nomlar - o'zgaruvchi nomi mazmunni ochib beryaptimi?
Takrorlanish - shu kod boshqa joyda ham bormi?
Testlar - yangi mantiq testlar bilan qoplanganmi?

Nimaga e'tibor bermaslik kerak:

Otstup va bo'sh joylar - buni avtomatik formatlovchi hal qilsin
Shaxsiy uslub afzalliklari - "men boshqacha yozgan bo'lardim"

Izoh yozish odobi #

Yomon	Yaxshi
"Bu kod juda yomon"	"Bu yerda `array_map` o'qishni osonlashtiradi deb o'ylayman"
"Nima uchun shunday qildingiz?!"	"Bu yondashuvni tanlash sababini tushuntira olasizmi?"
"Xato"	"Agar `$mahsulotlar` bo'sh bo'lsa, 14-satrda xatolik chiqadi"
"O'zgartiring"	"Buni alohida funksiyaga chiqarsak, testlash osonroq bo'ladi"

Kodni tanqid qiling, odamni emas

"Sizning kodingiz noto'g'ri" emas, "bu funksiya bo'sh massivda ishlamaydi".

Aniq, foydali va hurmatli izoh - jamoaning eng qimmatli odati.

Izoh turlari #

Natija

[blocker] Bu SQL inyeksiyaga ochiq - parametrlash kerak
[savol]   Bu yerda nima uchun tranzaksiya ishlatilmagan?
[taklif]  Bu shartni erta qaytish bilan soddalashtirsa bo'ladi
[nit]     Kichik: o'zgaruvchi nomi `x` emas, `mahsulotSoni` bo'lsa yaxshi

Muhimlik darajasini belgilang

[nit] (arzimas) belgisi muallifga "bu majburiy emas" degan signal beradi. [blocker] esa "buni tuzatmasdan merge qilmaymiz" degani.

Bu chalkashlikni yo'q qiladi va tekshiruvni tezlashtiradi.

Izohlarga javob #

Terminal

# Tuzatish kiritish
git add manba/hisobot.php
git commit -m "Tekshiruv izohlariga ko'ra tuzatildi: bo'sh massiv holati"
git push

PR avtomatik yangilanadi - yangi PR ochish shart emas.

Kommitlarni squash qilmang (PR ochiq turganda)

Agar --amend yoki rebase bilan tarixni o'zgartirsangiz, tekshiruvchi "nima o'zgardi?" ni ko'ra olmaydi.

Merge paytida squash qilish mumkin - lekin tekshiruv davomida emas.

Merge usullari #

Uchala usul ham to'g'ri - jamoada bittasini tanlab, unga amal qiling

Fork bilan ishlash #

Boshqa odamning loyihasiga hissa qo'shish uchun.

1. Fork qiling - GitHub saytida Fork tugmasi. Bu loyihaning nusxasini sizning hisobingizga ko'chiradi.

2. Klonlang:

Terminal

git clone git@github.com:siz/loyiha.git
cd loyiha

3. Asl loyihani upstream sifatida qo'shing:

Terminal

git remote add upstream https://github.com/asl-muallif/loyiha.git
git remote -v

Natija

origin    [email protected]:siz/loyiha.git (fetch)
origin    [email protected]:siz/loyiha.git (push)
upstream  https://github.com/asl-muallif/loyiha.git (fetch)
upstream  https://github.com/asl-muallif/loyiha.git (push)

4. Ishlang:

Terminal

git switch -c fix/hujjat-xatosi
# ... o'zgartirish ...
git commit -am "Hujjatdagi imlo xatosi tuzatildi"
git push -u origin fix/hujjat-xatosi

5. PR oching - GitHub o'zi taklif qiladi: sizning tarmog'ingizdan asl loyihaning main iga.

6. Fork ni yangilab turing:

Terminal

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Fork qachon kerak?

Sizga yozish huquqi berilmagan ochiq loyihalarda
Loyihaning o'z versiyangizni yaratmoqchi bo'lsangiz

Agar jamoa a'zosi bo'lsangiz va yozish huquqingiz bo'lsa - fork shart emas, to'g'ridan-to'g'ri tarmoq yaratasiz.

Draft PR #

Ish tugamagan bo'lsa ham PR ochish mumkin:

Terminal

gh pr create --draft --title "WIP: hisobot sahifasi"

Bu "hali tayyor emas, lekin ko'rib turing" degan signal. Draft PR ni merge qilib bo'lmaydi.

PR shabloni #

.github/pull_request_template.md fayli yarating:

MARKDOWN

## Nima qilindi


## Nima uchun


## Qanday tekshirish


## Tekshiruv ro'yxati

- [ ] Kod lokal ishga tushirilib sinaldi
- [ ] Testlar yozildi va o'tdi
- [ ] Hujjatlar yangilandi
- [ ] Migratsiya kerak bo'lsa qo'shildi

Har bir yangi PR shu shablon bilan ochiladi.

CODEOWNERS #

.github/CODEOWNERS fayli kim nimani tekshirishini belgilaydi:

Natija

# Standart
*                   @husanboy

# Frontend
/public/assets/     @jasur

# Baza
/database/          @malika @husanboy

# CI sozlamalari
/.github/           @husanboy

Tegishli fayl o'zgarganda GitHub avtomatik kerakli odamni tekshiruvga chaqiradi.

Tarmoqni himoyalash #

Settings → Branches → Add rule

Qoida	Nima beradi
Require pull request	To'g'ridan-to'g'ri push taqiqlanadi
Require approvals	Kamida N kishi tasdiqlashi kerak
Require status checks	Testlar o'tishi shart
Require conversation resolution	Barcha izohlar hal qilinishi kerak
Do not allow bypassing	Adminlar uchun ham majburiy

main ni himoyalang

Bu bitta sozlama "tasodifan main ga push qilib qo'ydim" muammosini butunlay yo'q qiladi.

Kichik jamoada ham foydali - o'zingizni o'zingizdan himoya qilasiz.

Amaliy topshiriq

GitHub da biror ochiq loyihani fork qiling (masalan hujjatlar loyihasi).
Uni klonlang va upstream remote qo'shing.
Tarmoq yarating va kichik o'zgartirish kiriting.
Push qiling va Pull Request oching.
PR tavsifini to'liq yozing: nima, nima uchun, qanday tekshirish.
O'z repozitoriyingizda .github/pull_request_template.md yarating.
main tarmog'ini himoyalang: PR majburiy qilib qo'ying.
Himoyalangan main ga to'g'ridan-to'g'ri push qilishga urinib ko'ring.
Do'stingizdan PR ingizga izoh yozishni so'rang va unga javob bering.

Xulosa #

Pull Request - o'zgarishlarni tekshirish va birlashtirish so'rovi.
PR ni kichik qiling - 400 satrdan katta PR aslida tekshirilmaydi.
PR tavsifida nima, nima uchun va qanday tekshirish bo'lsin.
Kod tekshiruvida kodni tanqid qiling, odamni emas.
[blocker], [taklif], [nit] belgilari izoh muhimligini bildiradi.
Uch merge usuli bor; ko'p jamoalar Squash and merge ni tanlaydi.
Fork - yozish huquqi bo'lmagan loyihalarga hissa qo'shish uchun.
upstream remote orqali fork ni asl loyiha bilan yangilab turing.
Tarmoq himoyasi tasodifiy push va tekshiruvsiz merge dan saqlaydi.

Keyingi bo'limda rebase va tarixni tozalashni o'rganamiz.

Ish oqimi #

PR yaratish #

Yaxshi PR tavsifi #

Kod tekshiruvi #

Tekshiruvchi sifatida #

Izoh yozish odobi #

Izoh turlari #

Izohlarga javob #

Merge usullari #

Fork bilan ishlash #

Draft PR #

PR shabloni #

CODEOWNERS #

Tarmoqni himoyalash #

Xulosa #

Xatolik topdingizmi?