GitHub'da code review amaliyoti

Qisqacha: Code review — kod main ga tushishidan oldin uni boshqa odam o'qib chiqishi. GitHub'da reviewer PR'ning Files changed tabida qatorlarga izoh qoldiradi, ```suggestion bloki bilan tayyor tuzatish taklif qiladi va oxirida uch qarordan birini yuboradi: **Comment**, **Approve** yoki **Request changes**. Muallif tuzatadi, push qiladi, suhbatlarni **Resolve conversation** bilan yopadi va qayta review so'raydi. CODEOWNERS fayli esa kerakli reviewer'ni avtomatik chaqiradi.

Bu darsda

• PR'ni reviewer ko'zi bilan o'qiysiz: brauzerda va o'z kompyuteringizda.
• Qatorga izoh, bir necha qatorga izoh va suggestion blokini yozasiz.
• Uch review qarorini farqlaysiz va nega o'z PR'ingizni tasdiqlay olmasligingizni bilasiz.
• Muallif sifatida izohlarga javob berasiz: suggestion'ni qabul qilish, --fixup, qayta review.
• CODEOWNERS faylini yozasiz va GitHub uni qanday o'qishini tekshirasiz.

Oldin bilishingiz kerak: Pull Request: yaratish, muhokama va merge, O'zgarishlarni ko'rish: git diff, Interaktiv rebase: PR'dan oldin tarixni tozalash.

1. Nega bu kerak?

Oldingi darsda PR ochdik va uni o'zimiz birlashtirdik. PR sahifasidagi muhokama qismi esa bo'sh qoldi. Bugun o'sha qismni to'ldiramiz.

Code review (kodni ko'rib chiqish) — kod main ga tushishidan oldin uni boshqa dasturchi o'qib, fikr bildirishi. Xuddi gazetadagi muharrir kabi: jurnalist maqolani yozadi, muharrir o'qib, xatolarni belgilaydi. Maqola muharrirdan o'tmaguncha chop etilmaydi.

Review nima beradi?

• Xatolar erta topiladi. Muallif o'z kodiga o'rganib qolgan, ko'zi "sirpanadi". Yangi ko'z boshqacha ko'radi.
• Bilim tarqaladi. Malika Azizning kodini o'qib, sayt qismini o'rganadi. Aziz kasal bo'lsa, ish to'xtamaydi.
• Kod bir xil uslubda yoziladi. Kelishuvlar — nomlar, tuzilma — review'da eslatiladi.

Versiya nazorati darsida "kod asosiy tarixga tushishidan oldin hamkasblar uni tekshiradi" degan edik. Mana o'sha jarayonning o'zi.

Bugun ikki rolni ham o'ynaymiz. Aziz — muallif: «Bahor»ning bron sahifasiga forma qo'shdi. Malika — reviewer: formani tekshiradi.

2. Muallif PR'ni review'ga tayyorlaydi

2.1 PR

Aziz feature/bron-formasi branch'ida ikki commit qildi va PR ochdi — oldingi darsdagi tartibda:

git log --oneline main..HEAD

d9c6ddc (HEAD -> feature/bron-formasi, origin/feature/bron-formasi) Aloqa: bron haqida eslatma qo'sh
8c14254 Bron: band qilish formasini qo'sh

Chiqishlar yana GitHub'dagi sinov reposidan, nomi login/bahor ga almashtirilgan. Bu PR'ning raqami #7.

2.2 Avval o'zingiz ko'ring

Reviewer chaqirishdan oldin Files changed ni o'zingiz oching va diff'ni boshdan oxirigacha o'qing. Bunga self-review (o'z-o'zini tekshirish) deyiladi. Bu bosqichda ko'p narsa topiladi: unutilgan TEST TEST qatori, vaqtincha qo'yilgan izoh, adashib qo'shilgan fayl. Malika vaqtini bunday mayda narsalarga sarflamasin.

2.3 Reviewer so'rash

PR sahifasining o'ng ustunida Reviewers bo'limi bor. GitHub hujjatiga ko'ra, GitHub taklif qilgan odam yonida Request tugmasi turadi. Boshqa odam kerak bo'lsa, Reviewers ni bosib, uning nomini yozasiz va tanlaysiz. U bildirishnoma oladi va PR uning "ko'rib chiqishim kerak" ro'yxatiga tushadi.

Har PR'da reviewer'ni qo'lda tanlash zerikarli. "Menyu fayllariga doim Jasur aka qarasin" kabi qoidani faylga yozish mumkin. Bu — CODEOWNERS, uni dars oxirida yozamiz.

3. Reviewer: PR'ni o'qish

3.1 Files changed

Malika PR #7 ni ochib, Files changed tabiga o'tdi. Bu yerda git diff darsidagi diff — qizil va yashil qatorlar, fayllar bo'yicha.

Ish tartibi:

1. Avval Conversation tabidagi tavsifni o'qing: nima va nega qilingan. Maqsadni bilmasangiz, kodni baholay olmaysiz.
2. Har faylni o'qing. Tushunib bo'lgach, fayl sarlavhasining o'ng tomonidagi Viewed belgisini qo'ying. GitHub hujjatiga ko'ra, fayl yig'ilib qoladi va qaysi fayllar qolganini ko'rasiz.
3. Savol yoki fikr tug'ilsa — o'sha qatorga izoh qoldiring (keyingi bo'lim).

3.2 PR'ni o'z kompyuteringizda ochish

Brauzerda o'qish har doim ham yetmaydi. Formani ko'rish uchun sahifani brauzerda ochib, maydonlarni to'ldirib ko'rish kerak. Buning uchun PR'ning kodi kompyuteringizda bo'lishi kerak.

PR'ning branch'i sizga notanish bo'lishi mumkin — u hatto boshqa odamning reposida bo'lishi mumkin (Fork darsida ko'rasiz). Lekin GitHub har PR uchun maxsus ref saqlaydi: pull/<raqam>/head. Malika shuni oladi:

cd ~/kurs/bahor
git fetch origin pull/7/head:pr-7

From https://github.com/login/bahor
 * [new ref]         refs/pull/7/head -> pr-7

pull/7/head:pr-7 — "GitHub'dagi pull/7/head ni lokal pr-7 branch'iga yoz". Endi u oddiy branch:

git log --oneline main..pr-7
git diff --stat main...pr-7

d9c6ddc (origin/feature/bron-formasi, pr-7) Aloqa: bron haqida eslatma qo'sh
8c14254 Bron: band qilish formasini qo'sh
 aloqa/index.html | 1 +
 bron/index.html  | 7 +++++++
 2 files changed, 8 insertions(+)

Uch nuqta (main...pr-7) — git diff darsidan: "ikki branch ajralgan joydan beri pr-7 da nima o'zgardi". Aynan PR'ning Files changed tabidagi narsa.

Asosiy ishni buzmaslik uchun PR'ni alohida papkada ochish qulay — Worktree darsida va'da qilganimizdek:

git worktree add ../bahor-review pr-7

Preparing worktree (checking out 'pr-7')
HEAD is now at d9c6ddc Aloqa: bron haqida eslatma qo'sh

Malika ../bahor-review/bron/index.html ni brauzerda ochib, formani sinadi. Ish tugagach — git worktree remove ../bahor-review. Uning o'z ishi esa asosiy papkada tegilmay turibdi.

Maslahat: gh pr checkout 7 buyrug'i shu ishni bitta qadamda qiladi. gh ni GitHub CLI darsida o'rganamiz.

3.3 Nimaga qarash kerak

Malika formani sinab, ikki narsani topdi:

+<form action="/bron" method="post">
+  <input type="text" name="ism" placeholder="Ismingiz">
+  <input type="tel" name="telefon" placeholder="Telefon">
+  <input type="date" name="sana">
+  <input type="number" name="odam" min="1">
+  <button type="submit">Yuborish</button>
+</form>

• Telefon maydoni majburiy emas. Mehmon uni bo'sh qoldirsa, choyxona unga qo'ng'iroq qila olmaydi.
• Odamlar soniga yuqori chegara yo'q. 500 kishi yozish mumkin, eng katta stol esa 50 kishilik.

Ikkalasi ham HTML formalarining required, max atributlari bilan tuzatiladi — 04-qismdan tanish.

Review'da odatda shu savollarni beradi:

4. Izoh va suggestion

4.1 Qatorga izoh

GitHub hujjatiga ko'ra, Files changed tabida qator ustiga sichqonchani olib borsangiz, ko'k izoh belgisi chiqadi. Uni bosib, izoh yozasiz. Bir necha qatorga izoh uchun birinchi qator raqamini bosib, oxirgisigacha sudrang. Yoki Shift ni bosib turib, oxirgi qator raqamini bosing. Butun faylga izoh — fayl sarlavhasining o'ng tomonidagi izoh belgisi orqali.

Izohni yozgach ikki yo'l bor:

• Add single comment — izoh darhol chiqadi, muallif darhol bildirishnoma oladi.
• Start a review — izoh hozircha faqat sizga ko'rinadi. Keyingi izohlar Add review comment bilan qo'shiladi, oxirida hammasi birga yuboriladi.

Odatda Start a review to'g'ri. Muallif o'nta bildirishnoma o'rniga bittasini oladi va hamma fikrni birga ko'radi.

4.2 Suggestion — tayyor tuzatish

"Telefonni majburiy qiling" deb yozish mumkin. Lekin undan ham yaxshisi — to'g'ri qatorni tayyor yozib berish. Buning uchun izohda maxsus ```suggestion bloki bor. Izoh oynasidagi "suggestion" belgisini bossangiz, GitHub tanlangan qatorni shu blokka o'zi solib beradi. Siz faqat uni tahrirlaysiz.

Malika telefon qatoriga shunday izoh yozdi:

Telefon majburiy bo'lsin — busiz qo'ng'iroq qila olmaymiz.

```suggestion
  <input type="tel" name="telefon" placeholder="Telefon" required>
```

Blok ichidagi matn — tanlangan qator(lar)ning yangi ko'rinishi. Bir necha qatorni tanlasangiz, blok ularning hammasini almashtiradi. Muallif uni bir tugma bilan qabul qila oladi — buni birozdan keyin ko'ramiz.

Ikkinchi izoh — maslahat darajasida:

nit: `max` ham qo'ying, 50 kishidan ortiq stol yo'q.

nit: — inglizcha "nitpick", "mayda gap" so'zidan. Reviewer'lar shu bilan "bu muhim emas, xohlasangiz tuzating" deb belgilaydi. Bunday kelishuvlarni Code review berish va olish darsida batafsil ko'rasiz.

4.3 Review qarori

Hamma izoh yozilgach, Files changed tepasidagi Review changes tugmasini bosasiz. Umumiy izoh yozib, uch qarordan birini tanlaysiz:

Va Submit review. Malika Comment ni tanladi va umumiy izohga yozdi: "Forma yaxshi. Ikki joyga qarab chiqing." Ikkala qator izohi shu review bilan birga yuborildi.

GitHub'dagi sinovda shu reviewni yaratdik. Natija (holati va umumiy izohi):

COMMENTED — Forma yaxshi. Ikki joyga qarab chiqing.

Qator izohlari esa fayl va qator raqami bilan saqlandi:

bron/index.html:5
Telefon majburiy bo'lsin — busiz qo'ng'iroq qila olmaymiz.

```suggestion
  <input type="tel" name="telefon" placeholder="Telefon" required>
```
---
bron/index.html:7
nit: `max` ham qo'ying, 50 kishidan ortiq stol yo'q.
---

4.4 O'z PR'ingizni tasdiqlab bo'lmaydi

Sinovda bitta GitHub akkaunti bor edi — PR muallifi ham, "reviewer" ham o'sha. Approve va Request changes ni yuborishga urinib ko'rdik. GitHub ikkalasini ham rad etdi:

failed to create review: GraphQL: Review Can not approve your own pull request (addPullRequestReview)
failed to create review: GraphQL: Review Can not request changes on your own pull request (addPullRequestReview)

Tarjimasi: "o'z pull request'ingizni tasdiqlab bo'lmaydi" va "o'z pull request'ingizdan o'zgarish talab qilib bo'lmaydi". GitHub hujjati ham buni aniq aytadi: PR mualliflari o'z PR'larini tasdiqlay olmaydi.

Mantiqi oddiy: review — boshqa ko'z. O'z ishini o'zi tasdiqlash hech narsani tekshirmaydi. Comment esa ruxsat: o'z PR'ingizga izoh yozib, reviewer'ga tushuntirish qoldirish foydali.

Tekshirib ko'ring: Malika bitta muhim xato topdi va uchta "nit:" yozdi. Qaysi qarorni tanlashi kerak?

5. Muallif: izohlarga javob

5.1 Suggestion'ni qabul qilish

Aziz izohlarni ochdi. Suggestion bloki ostida tugmalar bor. GitHub hujjatiga ko'ra:

• Commit suggestion — bitta taklifni darhol commit qiladi.
• Add suggestion to batch — taklifni navbatga qo'yadi. Bir nechta yig'ilgach, Commit suggestions hammasini bitta commitda qo'llaydi.

Buning uchun repoga yozish huquqi kerak. Taklif muallifi commitga hammuallif sifatida qo'shiladi — Malikaning hissasi tarixda qoladi.

Bir muhim nuqta: commit GitHub'da yaratiladi. Lokal branch'ingiz ortda qoladi. Keyingi ishdan oldin git pull qiling.

5.2 Yoki o'zingiz tuzatasiz — --fixup

max uchun suggestion yo'q edi. Aziz ikkala tuzatishni lokal qildi:

git diff

diff --git a/bron/index.html b/bron/index.html
index 442f0ff..fa39dc2 100644
--- a/bron/index.html
+++ b/bron/index.html
@@ -2,8 +2,8 @@
 <p>Tel: +998 90 000 00 00</p>
 <form action="/bron" method="post">
   <input type="text" name="ism" placeholder="Ismingiz">
-  <input type="tel" name="telefon" placeholder="Telefon">
+  <input type="tel" name="telefon" placeholder="Telefon" required>
   <input type="date" name="sana">
-  <input type="number" name="odam" min="1">
+  <input type="number" name="odam" min="1" max="50">
   <button type="submit">Yuborish</button>
 </form>

Tuzatish formani qo'shgan commitga tegishli. Interaktiv rebase darsida aynan shu holat uchun --fixup ni o'rgangan edik:

git add bron
git commit --fixup HEAD~1
git push

[feature/bron-formasi 9c18d0c] fixup! Bron: band qilish formasini qo'sh
 1 file changed, 2 insertions(+), 2 deletions(-)
To https://github.com/login/bahor.git
   d9c6ddc..9c18d0c  feature/bron-formasi -> feature/bron-formasi

HEAD~1 — "oxirgidan oldingi commit", ya'ni 8c14254. Nega darhol --autosquash qilmadik? Reviewer uchun. Malika endi faqat fixup! commitini ochib, "nima o'zgardi?" savoliga bir qarashda javob oladi. Hamma narsani qaytadan o'qish shart emas.

5.3 Merge'dan oldin tozalash

Malika tuzatishni ko'rib, rozi bo'ldi. Endi fixup! commit tarixda qolmasligi kerak:

git rebase -i --autosquash main
git log --oneline main..HEAD

Successfully rebased and updated refs/heads/feature/bron-formasi.
d5a71fd (HEAD -> feature/bron-formasi) Aloqa: bron haqida eslatma qo'sh
8bc7a72 Bron: band qilish formasini qo'sh

Ikki toza commit. Ularni yuboramiz:

git push

To https://github.com/login/bahor.git
 ! [rejected]        feature/bron-formasi -> feature/bron-formasi (non-fast-forward)
error: failed to push some refs to 'https://github.com/login/bahor.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
...

Tanish xato — Ajralgan tarix darsidan. Rebase tarixni qayta yozdi, GitHub'dagi branch esa eski tarixda. Bu yerda git pull maslahati noto'g'ri: u eski commitlarni qaytarib olib keladi. To'g'ri yo'l — o'sha darsdagi xavfsiz majburiy push:

git push --force-with-lease

To https://github.com/login/bahor.git
 + 9c18d0c...d5a71fd feature/bron-formasi -> feature/bron-formasi (forced update)

PR'ning Commits tabida endi ikki commit. Bu branch'da faqat Aziz ishlaydi — shuning uchun tarixni qayta yozish xavfsiz. Boshqa odam ham shu branch'ga commit qilayotgan bo'lsa, avval kelishib oling (Rebase darsidagi oltin qoida).

Diqqat: Review jarayonida, Malika tuzatishni ko'rmasdan, rebase va force push qilmang. Uning ko'rib bo'lgan narsasi ham, yangisi ham bitta aralash tarixga aylanadi. Avval --fixup bilan oddiy push, merge'dan oldin tozalash.

5.4 Eskirgan izohlar va Resolve conversation

Izoh qoldirilgan qatorlar o'zgardi. GitHub bunday izohni outdated (eskirgan) deb belgilaydi va kichraytiradi — u endi kodning eski versiyasiga tegishli. Sinovdagi ikkala izoh shunday belgilandi.

Har izoh — alohida suhbat (conversation). Tuzatilgach, uni Resolve conversation tugmasi bilan yopiladi. GitHub hujjatiga ko'ra, buni PR muallifi yoki repoga yozish huquqi bor odam qila oladi. Yopilgan suhbatlar yig'iladi va ochiq qolgan fikrlar darhol ko'rinadi.

Odob qoidasi: shunchaki "Resolve" bosmang. Qisqa javob yozing — "Tuzatildi, 9c18d0c" yoki "Bu PR'da emas, alohida issue ochdim". Reviewer fikri e'tiborsiz qolmaganini ko'radi.

5.5 Qayta review so'rash

Tuzatishlar tayyor. Muallif Malikaga xabar beradi: GitHub hujjatiga ko'ra, Reviewers bo'limida reviewer ismi yonida aylana strelkali "sync" belgisi bor. Uni bossangiz, qayta review so'raladi. Malika yana bildirishnoma oladi.

sequenceDiagram
  participant A as Aziz (muallif)
  participant G as GitHub PR #7
  participant M as Malika (reviewer)
  A->>G: push, PR ochish
  A->>G: Reviewers: Malika
  G->>M: bildirishnoma
  M->>G: izohlar + suggestion
  G->>A: review: Comment
  A->>G: fixup commit, push
  A->>G: qayta review so'rash
  M->>G: Approve
  A->>G: autosquash, force-with-lease
  A->>G: Squash and merge

Nimaga qarang: Aziz va Malika bir-biriga to'g'ridan-to'g'ri yozmaydi. Hamma narsa PR orqali o'tadi va tarixda qoladi. Uch oydan keyin ham "telefon nega majburiy?" savoliga javob shu PR'da.

Real jamoada Malika Approve bosgandan keyin merge qilinadi. Bizning sinovda Approve imkonsiz edi, shuning uchun PR #7 ni Squash and merge bilan birlashtirdik.

6. CODEOWNERS — reviewer'ni avtomatik chaqirish

6.1 Fayl

CODEOWNERS (kod egalari) — "qaysi faylga kim javobgar" ro'yxati. GitHub hujjatiga ko'ra, kimdir egasi bor faylni o'zgartirgan PR ochsa, ega review'ga avtomatik chaqiriladi.

Fayl uch joyda turishi mumkin: .github/, repo ildizi yoki docs/. GitHub aynan shu tartibda qidiradi va birinchi topganini ishlatadi. Biz .github/ ni tanladik:

# Har qator: fayl shabloni va uning egalari.
# Oxirgi mos kelgan qator ustun turadi.

# Standart: hamma fayl
*              @login

# Menyu narxlari — Jasur aka ham ko'rsin
/menyu/        @login @jasur-aka-bahor-yoq

# Sozlama fayllari
.github/       @login

Har qator — shablon va egalar. Shablonlar .gitignore dagiga o'xshaydi. Ega — @foydalanuvchi, @tashkilot/jamoa yoki email.

Eng muhim qoida — oxirgi mos kelgan qator ustun. menyu/index.html uchun * ham, /menyu/ ham mos keladi. Pastdagisi g'olib, shuning uchun menyuga ikki ega. GitHub hujjati yana ikki farqni aytadi: ! bilan inkor qilish va # bilan boshlanadigan shablon CODEOWNERS'da ishlamaydi.

Tekshirib ko'ring: Shu fayl bo'yicha .github/CODEOWNERS ni o'zgartirgan PR'ga kim chaqiriladi? assets/css/asosiy.css ni-chi?

6.2 GitHub faylni tekshiradi

Faylda ataylab xato qoldirdik: @jasur-aka-bahor-yoq degan foydalanuvchi yo'q. CODEOWNERS main ga qo'shilgach, GitHub'dan xatolar ro'yxatini so'radik:

8: Unknown owner — Unknown owner on line 8: make sure @jasur-aka-bahor-yoq exists and has write access to the repository

  /menyu/        @login @jasur-aka-bahor-yoq
                                ^

Tarjimasi: "8-qatorda noma'lum ega: @jasur-aka-bahor-yoq mavjudligiga va repoga yozish huquqi borligiga ishonch hosil qiling". GitHub hujjatiga ko'ra, xato bor qator butunlay tashlab ketiladi. Demak /menyu/ qatori ishlamaydi — menyu fayllariga yana * qatoridagi @login chaqiriladi. PR'da hech kim ogohlantirmaydi, faqat kutilgan reviewer kelmaydi. Xatoni ko'rish yo'li — GitHub hujjatiga ko'ra, CODEOWNERS faylini GitHub'da ochsangiz, xatolar belgilangan holda ko'rinadi.

6.3 Qachon ishlaydi, qachon yo'q

GitHub hujjatidagi shartlar:

• Fayl PR'ning base branch'ida bo'lishi kerak. CODEOWNERS'ni qo'shgan PR'ning o'zida u hali ishlamaydi.
• Egalar repoga yozish huquqiga ega bo'lishi kerak.
• Draft PR'ga egalar avtomatik chaqirilmaydi. Ready for review bosilganda chaqiriladi.
• Fayl hajmi 3 MB dan kichik bo'lsin.

Sinovda yana bir narsa ko'rindi. PR #7 ni @login ning o'zi ochdi, u esa bron/ ning egasi. Reviewer so'rovlari ro'yxati bo'sh qoldi — muallif o'z PR'iga reviewer bo'lib chaqirilmaydi.

CODEOWNERS'ning asl kuchi Branch himoyasi bilan ochiladi: Require review from Code Owners sozlamasi yoqilsa, ega tasdiqlamaguncha PR merge bo'lmaydi. Katta loyihalarda u qanday tuzilishini Monorepo va Git darsida ko'rasiz.

7. Yaxshi review madaniyati

Review — texnik ish, lekin uni odamlar qiladi. Bir xil fikrni ikki xil aytish mumkin:

Reviewer uchun:

• Kodni tanqid qiling, odamni emas.
• Sababini yozing: "chunki..." — muallif o'rganadi.
• Muhimini maydadan ajrating (nit:).
• Yaxshi joyni ham ayting.

Muallif uchun:

• Izoh — sizga emas, kodga. Xafa bo'lmang.
• Har izohga javob bering: tuzatdim yoki nega rozimasligingizni tushuntiring.
• Kichik PR yuboring — 50 qatorni sinchiklab o'qishadi, 2 000 qatorni esa yuzaki.

8. Ko'p uchraydigan xatolar

8.1 Izohlar "Pending" bo'lib qoldi

Malika uchta izoh yozib, Start a review bosdi va sahifani yopdi. Aziz hech narsa ko'rmadi. Sabab: Submit review bosilmagan, izohlar hali qoralama. Tuzatish: Review changes → qaror → Submit review.

8.2 Commit suggestion tugmasi yo'q

Sardor kursdoshining PR'ida suggestion'ni ko'rdi, lekin uni qabul qila olmadi. GitHub hujjatiga ko'ra, suggestion'ni qo'llash uchun repoga yozish huquqi kerak. Sardorda esa faqat o'qish huquqi bor. Tuzatish: taklifni PR muallifi yoki repoga yozish huquqi bor odam qabul qiladi.

8.3 Force push'dan keyin reviewer nusxasi

Malika pr-7 ni lokal olgan edi. Aziz force push qildi. Malika yangilamoqchi bo'ldi:

git fetch origin pull/7/head:pr-7

From https://github.com/login/bahor
 ! [rejected] refs/pull/7/head -> pr-7  (non-fast-forward)

Tarjimasi: "rad etildi: fast-forward emas". PR'dagi yangi commitlar pr-7 ning davomi emas — tarix qayta yozilgan. Git lokal branch'ni ehtiyot bo'lib himoya qildi. Tuzatish: pull/7/head:pr-7 yozuvi (uni refspec deyishadi — "qayerdan:qayerga" ko'rsatmasi) oldiga + qo'yiladi — "majburan yangila". pr-7 sizning branch'ingiz emas, shuning uchun bu xavfsiz:

git fetch origin +pull/7/head:pr-7

From https://github.com/login/bahor
 + d9c6ddc...d5a71fd refs/pull/7/head -> pr-7  (forced update)

8.4 CODEOWNERS ishlamaydi

Uch sabab bor: fayl PR'ning base branch'ida emas; ega nomi xato yoki unda yozish huquqi yo'q («GitHub faylni tekshiradi» bo'limidagi kabi); pastroqdagi boshqa qator ustun keldi. Tuzatish: fayl sahifasida xatolarni ko'ring va qatorlar tartibini tekshiring.

9. Mashqlar

1-mashq (oson): Qaror tanlang

Har review uchun qarorni tanlang (Comment, Approve, Request changes):

1. Kod to'g'ri, faqat bitta "nit: bo'sh qator ortiqcha".
2. Forma yuborilganda sahifa xato beradi.
3. Siz CSS'ni yaxshi bilmaysiz, faqat HTML qismi haqida savolingiz bor.

2-mashq (o'rta): Suggestion yozing

Reviewer sifatida aloqa sahifasidagi shu qatorga suggestion yozing — telefon raqami bosiladigan havola bo'lsin:

<p>Tel: +998 90 000 00 00</p>

Telefonda bosib qo'ng'iroq qilish qulay bo'lsin.

```
<p>Tel: <a href="tel:+998900000000">+998 90 000 00 00</a></p>
```

Ishora: «Suggestion — tayyor tuzatish» bo'limi. Blok nomi qanday?

```suggestion
<p>Tel: <a href="tel:+998900000000">+998 90 000 00 00</a></p>
```

3-mashq (qiyin): CODEOWNERS'ni o'qing

*.css          @malika
/menyu/        @jasur
*              @aziz

1. menyu/index.html ni o'zgartirgan PR'ga kim chaqiriladi?
2. assets/css/asosiy.css ni-chi?
3. Muallif kutgan narsa — CSS fayllarga Malika, menyuga Jasur. Faylni qanday tuzatish kerak?

Ishora: «CODEOWNERS» bo'limidagi eng muhim qoida.

*              @aziz
*.css          @malika
/menyu/        @jasur

4-mashq: Portfolio qadami — o'z PR'ingizga review

Portfolio'da hozircha yolg'iz ishlaysiz. Lekin review'ning muallif tomonini to'liq mashq qilsa bo'ladi: o'z PR'ingizga izoh va suggestion qoldirib, uni qabul qilish.

1. .github/CODEOWNERS faylini yarating: * @login (o'z nomingiz). Commit xabari: Sozlama: CODEOWNERS faylini qo'sh. Uni PR orqali main ga qo'shing. Branch nomi — chore/codeowners: Branch nima darsidagi jadvalni eslang, chore/ — sozlama kabi xizmat ishlari uchun.
2. Yangi branch'da portfolio bosh sahifasiga bitta jumla qo'shing va PR oching.
3. Files changed da o'z qatoringizga suggestion yozing — jumlani yaxshilang. Start a review emas, Add single comment ishlating.
4. Commit suggestion bilan qabul qiling. Lokal branch'ingiz endi ortda — git pull qiling va git log --oneline -3 bilan suggestion commitini ko'ring.
5. Izohga "Qabul qilindi" deb javob yozing va Resolve conversation bosing.
6. PR'ni merge qiling, lokal tozalashni bajaring.

cd ~/kurs/portfolio
git switch main
git pull
git switch -c chore/codeowners
mkdir -p .github
echo '* @login' > .github/CODEOWNERS
git add .github
git commit -m "Sozlama: CODEOWNERS faylini qo'sh"
git push -u origin chore/codeowners

git pull
git log --oneline -3

10. Real ishda

• Review — ish vaqtining bir qismi. Ko'p jamoalarda dasturchi kuniga bir-ikki soatini boshqalarning PR'iga sarflaydi. "Review kutayotgan PR" — jamoaning eng sekin joyi, shuning uchun tez javob qadrlanadi.
• Majburiy review. main ga kamida bitta Approve siz merge qilib bo'lmaydi — buni Branch himoyasi sozlaydi. Ochiq kodli loyihalarda CODEOWNERS katta loyihani o'nlab jamoa orasida bo'lib beradi: har jamoa faqat o'z papkasiga javob beradi.
• Avtomatik reviewer'lar. Kodni avtomatik tekshiruvchilar (linter, testlar) va AI yordamchilar ham PR'ga izoh yozadi. Ular mayda xatolarni ushlaydi, odam esa mantiq va dizaynga qaraydi.
• Intervyuda so'raladi: "Yaxshi code review qanday bo'ladi?", "Siz bilan rozi bo'lmagan izohga qanday javob berasiz?" Bu dars va Code review berish va olish darsi javob beradi.

Xulosa

• Code review — kod main ga tushishidan oldin boshqa odamning tekshiruvi; xatolarni ushlaydi va bilimni tarqatadi.
• Reviewer Files changed da qatorga izoh yozadi va ```suggestion bloki bilan tayyor tuzatish beradi.
• Start a review izohlarni yig'adi; Submit review ularni Comment, Approve yoki Request changes qarori bilan yuboradi.
• O'z PR'ingizni Approve yoki Request changes qilib bo'lmaydi.
• PR'ni lokal ko'rish: git fetch origin pull/<raqam>/head:pr-<raqam>, kerak bo'lsa worktree'da.
• Muallif: Commit suggestion yoki --fixup + push; merge'dan oldin --autosquash va --force-with-lease; suhbatni javob bilan Resolve.
• CODEOWNERS (.github/, ildiz yoki docs/): oxirgi mos qator ustun, xato qator jimgina tashlab ketiladi.

Keyingi dars: Fork va upstream: boshqaning loyihasiga hissa qo'shish — yozish huquqingiz yo'q repoga qanday PR yuborishni o'rganamiz.

Manbalar

• GitHub Docs: "Reviewing proposed changes in a pull request", "Commenting on a pull request", "About pull request reviews" — docs.github.com
• GitHub Docs: "Incorporating feedback in your pull request" — docs.github.com
• GitHub Docs: "About code owners" — docs.github.com
• Git hujjati: "git-fetch" (refspec), "git-worktree", "git-push" (--force-with-lease) — git-scm.com/docs