Yangi loyihaga kirish: arxitektura xaritasi, git tarixi va birinchi vazifa

Qisqacha: Yangi loyihada birinchi hafta tartib bilan o'tsa, foydali bo'lish uchun oylab kutish shart emas. Tartib: hujjatlarni o'qish (README, CONTRIBUTING), loyihani lokal ishga tushirish va testlarni yashil ko'rish. Keyin arxitektura xaritasini chizish (jarayonlar, papkalar, so'rov yo'li) va git log bilan tarixni o'qish: kim, qachon, qaysi fayllar eng ko'p o'zgaradi. Oxirida — kichik birinchi vazifa (good first issue). Savollarni yozib boring — javobi hujjatda yo'q savol hujjatning keyingi bo'limi bo'ladi. Kanonda vazifalar-api uchun docs/ARXITEKTURA.md yozildi va kurs sinov reposida birinchi vazifa issue'si ochildi.

Bu darsda

• Notanish loyihaga kirishning birinchi hafta rejasini tuzasiz.
• git log, git shortlog va bitta quvur bilan loyihaning "qaynoq" fayllari va mutaxassislarini topasiz.
• Kirish nuqtalaridan boshlab arxitektura xaritasini chizasiz.
• good first issue tanlab, uni qanday boshlashni bilasiz.
• vazifalar-api uchun docs/ARXITEKTURA.md yozasiz.

Oldin bilishingiz kerak: Begona repoda orientatsiya, Begona kodni o'qish, Kod arxeologiyasi: blame, log -S, log -L, Issues, Projects va shablonlar, Git konfiguratsiyasi.

1. Nega bu kerak?

Tasavvur qiling: Nodira kompaniyaga kirdi. Birinchi kuni unga repo havolasini berishdi: 145 ta TypeScript fayli, 27 ta migratsiya, to'rt xil jarayon. Jamoa band. Nodira ikki kun fayllarni tasodifiy ochib o'tirdi va hech narsa yozmadi. Uchinchi kuni bitta qatorlik tuzatish uchun yarim kun sarfladi — testlar lokal ishlamagan ekan.

Muammo Nodiraning bilimida emas. Unga yo'l kerak edi: nimani birinchi o'qish, nimani hozircha e'tiborsiz qoldirish, kimdan so'rash. Bu jarayon onboarding (loyihaga kirish) deyiladi. Yaxshi jamoada u hujjat bilan qo'llab-quvvatlanadi, yomonida — har kim o'zi qiynaladi.

Hayotiy o'xshatish: notanish shaharga ko'chdingiz. Birinchi kuni har ko'chani yurib chiqmaysiz. Avval xarita: markaz qayerda, uy qayerda, bozor qayerda. Keyin bir-ikki kerakli yo'lni yodlaysiz. Qolgan ko'chalar kerak bo'lganda o'rganiladi. Kod bazasi ham shunday — hammasini bilish shart emas, xarita va bir-ikki yo'l yetadi.

Begona repoda orientatsiya darsida ildiz fayllaridan stack va skriptlarni 15 daqiqada aniqlagansiz. Bu dars — keyingi qadam: kod tuzilishi, tarix va jamoa.

2. Birinchi hafta rejasi

flowchart TD
  A["1. Hujjatlar:<br/>README, CONTRIBUTING"] --> B["2. Lokal ishga tushirish:<br/>testlar yashil"]
  B --> C["3. Xarita:<br/>jarayonlar, papkalar"]
  C --> D["4. Tarix:<br/>git log, qaynoq fayllar"]
  D --> E["5. Birinchi vazifa:<br/>good first issue"]
  E --> F["6. Kichik PR"]
  A -.-> Q["Savollar ro'yxati"]
  C -.-> Q
  D -.-> Q

Qadamlarni tepadan pastga o'qing. Uzuq chiziqlar — har qadamda paydo bo'ladigan savollar. Ular bitta ro'yxatga yoziladi va kuniga bir marta jamoaga beriladi: har savol uchun hamkasbni bezovta qilmaysiz, lekin savolni yo'qotmaysiz ham.

Tartib ataylab shunday. Testlar lokal ishlamasa, keyingi qadamlarning hammasi taxmin bo'lib qoladi. Xaritasiz tarix o'qish — sahifalarni tasodifiy varaqlash. Tarixni bilmasdan vazifa — boshqalar allaqachon yechgan muammoga qaytish.

3. Hujjatlar: nima qidiramiz

Birinchi soatda uchta savolga javob qidiring:

1. Loyiha nima qiladi va kim uchun? — README boshi.
2. Qanday ishga tushiriladi? — README'dagi "tez boshlash", package.json skriptlari, .env.example.
3. O'zgarish qanday kiritiladi? — CONTRIBUTING.md: branch nomlari, commit formati, PR qoidalari, review.

docs/ papkasi bo'lsa — ro'yxatini ko'ring, lekin hammasini o'qimang. Nomlari yetarli: AUTH-QAROR.md, XAVFSIZLIK.md — ularga birinchi auth vazifasida qaytasiz.

Hujjat eskiradi — buni yodda tuting. Kanon ARXITEKTURA.md PR'ining tavsifida "75 ta test fayl" deb yozilgan edi. Biz loyihaning o'sha bosqichini sanadik:

find src -name '*.ts' | wc -l
find src -name '*.ts' -exec cat {} + | wc -l
find test -name '*.ts' | wc -l

145
11842
79

145 ta manba fayl, 11 842 qator, 79 ta test papkasidagi fayl (ulardan 70 tasi *.test.ts, qolgani yordamchi). Hech biri "75" emas. Kichik farq — lekin saboq katta: hujjatdagi raqam bir kunlik ham bo'lsa, tekshirilmagan bo'lishi mumkin. Shubha tug'ilsa — buyruq bilan o'zingiz tekshiring va farqni PR bilan tuzating. Yangi odamning toza ko'zi bunday xatolarni eng yaxshi ko'radi.

4. Lokal ishga tushirish

Ikkinchi qadam — loyiha sizning kompyuteringizda ishlasin va npm run check yashil bo'lsin. Kanon ARXITEKTURA.md dagi bo'lim (aynan):

## 5. Lokal ishga tushirish (30 daqiqada)

1. Node 24, Docker. `npm ci` (postinstall — `prisma generate`).
2. Postgres 18 + pgvector va Redis — [README](../README.md) dagi
   `docker run` buyruqlari (faqat `127.0.0.1`).
3. `cp .env.example .env` → `SAQLASH=postgres`, `DATABASE_URL`,
   `REDIS_URL`.
4. `npm run db:migrate && npm run db:seed` → `npm run start:dev` →
   `http://127.0.0.1:3000/docs`.
5. `npm run check` — tip, lint, test, build. Yashil bo'lmasa — PR
   ochilmaydi.

Uzun qatorlar telefon uchun bo'lindi, mazmun aynan. Sarlavhadagi "30 daqiqada" — va'da. Agar sizda bir soat ketsa, bu sizning emas, hujjatning xatosi: qayerda to'xtaganingizni yozib qo'ying.

Nima uchun aynan npm run check? U to'rt narsani birdaniga tekshiradi: tiplar, lint, testlar va build. Birinchi kunning maqsadi — shu buyruq yashil. Shundan keyin har o'zgarishingizdan so'ng "men buzdimmi?" degan savolga javob bor.

Kanon ham shu yo'ldan o'tdi. 32-qism boshida loyiha yangi papkaga ko'chirilib, kod o'zgarmagan holda npm run test ishga tushirildi. Birinchi yugurish:

 Test Files  3 failed | 64 passed | 1 skipped (68)
      Tests  1 failed | 334 passed | 5 skipped (340)

Kod bir xil, lekin testlar qizil. Kanon sababni muhitdan topdi: 29-qism testlari uchun TLS sinov sertifikati yangi papkaga nusxalanmagan edi, shu payt parallel npm install ham mashinani yuklagan edi. Sertifikat qo'shilib, yuksiz qayta yugurildi:

      Tests  339 passed | 1 skipped (340)

Yiqilgan test har doim ham kod xatosi emas — ko'pincha muhit farqi. Aynan shuning uchun bunday narsalar hujjatga yoziladi.

Tekshirib ko'ring: Birinchi kuni npm run check da bitta test yiqildi, qolgan 345 tasi o'tdi. Hamkasbingiz "menda o'tadi" dedi. Birinchi nima qilasiz?

5. Git tarixi: loyiha qanday o'sgan

5.1 O'quv loyiha

Kod — hozirgi holat. Tarix — nega shunday ekani. Kod arxeologiyasi darsida bitta faylni qazigansiz. Endi butun loyihaga qaraymiz. Mashq uchun kichik "begona" loyiha: kurs/mashqlar/32/09-kirish/begona-yarat.sh uni yaratadi — choyxona bron API'si, uch muallif, 12 commit. Muallif va sanalar qotirilgan, shuning uchun hash'lar sizda ham shunday chiqadi.

bash begona-yarat.sh choyxona-bron
cd choyxona-bron
git ls-files | cut -d/ -f1 | sort | uniq -c

      1 README.md
      1 docs
      1 package.json
      4 src
      2 test

Birinchi buyruq — papkalar xaritasi: har ildiz papkada nechta fayl. cut -d/ -f1 — yo'lning birinchi bo'lagi, uniq -c — sanash (Oqimlar, pipe va yo'naltirish darsi). Katta loyihada bu bir qarashda "og'irlik qayerda" ekanini ko'rsatadi.

5.2 Boshi va oxiri

git log --reverse --format='%ad %an: %s' --date=short | head -3
git log -3 --format='%ad %an: %s' --date=short

2026-09-01 Aziz Karimov: feat: loyiha skeleti
2026-09-03 Aziz Karimov: feat(bron): stol bron qilish
2026-09-05 Nodira Rahimova: feat(narx): mehmon soniga qarab narx
2026-10-09 Nodira Rahimova: fix(narx): tiyinlar yaxlitlanadi
2026-10-05 Sardor Aliyev: refactor(server): marshrutlar ulandi
2026-10-02 Nodira Rahimova: feat(narx): juma kuni ustama

Birinchi uch qator — loyiha qanday boshlangan (--reverse — eskidan yangiga). Keyingi uchtasi — hozir nima bilan band. Commit xabarlari Conventional Commits formatida bo'lsa, qavs ichidagi qamrov (bron, narx) modul nomlarini o'zi aytib beradi.

5.3 Kim nimani biladi

git shortlog -sn HEAD

     5	Nodira Rahimova
     4	Aziz Karimov
     3	Sardor Aliyev

shortlog -sn — muallif bo'yicha commitlar soni, ko'pidan kamiga. Bitta fayl bo'yicha ham bo'ladi: git shortlog -sn HEAD -- src/narx.js — bizda faqat Nodira. Demak narx haqida savolni kimga berishni bilasiz. Bu "kim ko'proq ishlaydi" degan baho emas: commit soni odamning hissasini o'lchamaydi. Bu faqat "kim shu kodni yaxshi biladi" degan ishora.

5.4 Qaynoq fayllar

Eng foydali bitta quvur — qaysi fayl eng ko'p o'zgargan:

git log --format= --name-only | sort | uniq -c \
  | sort -rn | head -4

      5 src/narx.js
      3 src/bron.js
      2 src/server.js
      2 src/config.js

--format= — commit sarlavhasini chiqarmaslik, --name-only — faqat o'zgargan fayl nomlari. Keyin sanash va saralash. Ko'p o'zgaradigan fayl — qaynoq fayl (hotspot): biznes mantig'i yoki tez-tez buziladigan joy. narx.js 12 commitdan 5 tasida — loyihaning yuragi shu. Birinchi o'qiladigan fayllar ro'yxati tayyor.

5.5 Bitta faylning hikoyasi

git log --format='%h %ad %an: %s' --date=short -- src/narx.js

61f8060 2026-10-09 Nodira Rahimova: fix(narx): tiyinlar yaxlitlanadi
9ac748c 2026-10-02 Nodira Rahimova: feat(narx): juma kuni ustama
95e82c6 2026-09-20 Nodira Rahimova: fix(narx): chegirma 15 foiz
f0f8ebc 2026-09-12 Nodira Rahimova: feat(narx): 10 kishidan chegirma
9465cf5 2026-09-05 Nodira Rahimova: feat(narx): mehmon soniga qarab narx

Besh qatorda funksiyaning butun hayoti: oddiy narx → chegirma → chegirma o'zgardi → juma ustamasi → yaxlitlash. Kodda chegirma = son >= 10 ? 0.15 : 0 ni ko'rib "nega 15?" deb hayron bo'lardingiz. Tarix javob beradi: avval 10 % edi, keyin ataylab o'zgartirilgan (95e82c6).

Qaysi commit biror so'zni olib kirgan — git log -S (Kod arxeologiyasi darsidagi "pickaxe"):

git log -S"chegirma" --format='%h %s' -- src/narx.js

f0f8ebc feat(narx): 10 kishidan chegirma

5.6 Kanon: vazifalar-api tarixi

Xuddi shu quvurni kanon 31-qism tarixida (9 commit, har biri qismning bir bosqichi) ishga tushirdik:

      6 package.json
      6 package-lock.json
      6 API.md
      5 src/tokenlar.ts
      4 src/app.module.ts
      4 src/ai/ai.module.ts

Birinchi uchtasi kutilgan: har bosqichda bog'liqlik va API hujjati o'zgargan. Qiziq joyi — keyingilari. src/tokenlar.ts — Custom provider'lar darsidagi bog'liqlik tokenlari: har yangi xizmat shu yerda ro'yxatga olinadi. app.module.ts — modullar ulanadigan joy. Demak loyihaga kirgan odam uchun bu ikki fayl — "markaziy bekat": ulardan boshlab qolgan hamma modulga yo'l bor.

Sizning vazifalar-api tarixingizda commitlar ko'proq va boshqacha — natija ham boshqacha bo'ladi. Shuning uchun buyruqni o'z repo'ngizda ishga tushiring.

Tekshirib ko'ring: Qaynoq fayllar ro'yxatida birinchi o'rinda package-lock.json turibdi. Bu fayl loyihaning "yuragi"mi?

6. Arxitektura xaritasi

6.1 Kirish nuqtalaridan boshlang

Xarita chizishni fayllardan emas, jarayonlardan boshlang: loyiha nechta dastur sifatida ishga tushadi? Javob package.json skriptlarida. Kanon loyihasining shu bosqichidan:

grep -o '"[a-z:]*": "node[^"]*dist/[a-z]*\.js"' package.json

"start": "node --env-file-if-exists=.env dist/main.js"
"buyruq": "node --env-file-if-exists=.env dist/buyruq.js"
"ishchi": "node --env-file-if-exists=.env dist/ishchi.js"
"bot": "node --env-file-if-exists=.env dist/bot.js"
"mcp": "node --env-file-if-exists=.env dist/mcp.js"

Beshta kirish nuqtasi: HTTP API (main), boshqaruv buyruqlari (buyruq), navbat ishchisi, Telegram bot va MCP server. Bitta kod bazasi — besh xil dastur. Har birining src/<nom>.ts fayli — o'qishni boshlash joyi.

6.2 Xaritani chizing

Keyin har jarayon nimaga ulanishini yozing. Kanon xaritasining soddalashtirilgan ko'rinishi (to'liq variantda middleware, guard va omborlar ham bor):

flowchart LR
  B["Brauzer"] -->|HTTP /v1| API["main.ts<br/>HTTP API"]
  AG["AI agent"] -->|stdio| MCP["mcp.ts"]
  MCP -->|HTTP + API kalit| API
  TG["Telegram"] <--> BOT["bot.ts"]
  API --> PG[("PostgreSQL")]
  API --> R[("Redis")]
  API -->|LLM| LLM["Gemini"]
  ISH["ishchi.ts"] --> PG
  ISH --> R
  BOT --> PG

Nimaga qarang: MCP server bazaga to'g'ridan ulanmaydi — u API'ning oddiy mijozi. Bot esa bazaga to'g'ridan yozadi. Bunday farqlar xaritasiz ko'rinmaydi, lekin xavfsizlik va o'zgarishlar uchun muhim: API'dagi ruxsat tekshiruvi botga ta'sir qilmaydi.

Xarita uch qatlamdan iborat bo'lsa yetadi:

1. Jarayonlar va tashqi tizimlar — yuqoridagi diagramma.
2. Bitta so'rov yo'li — masalan, POST /v1/vazifalar qaysi qatlamlardan o'tadi. Kanon buni sequenceDiagram bilan chizdi: middleware → guard → pipe → controller → servis → ombor → RLS → trigger → outbox.
3. Papkalar jadvali — har papka nima uchun javob beradi va qaysi qismda paydo bo'lgan.

Professional dunyoda bunday chizmalar uchun C4 modeli ko'p ishlatiladi: kontekst, konteynerlar, komponentlar, kod — to'rt daraja yaqinlashish, xuddi xaritani kattalashtirib borgandek (c4model.com, 2026-11). Bizning birinchi diagramma — taxminan uning "konteynerlar" darajasi.

6.3 Xaritani nega yozib qoldirish kerak

Xaritani o'zingiz uchun chizasiz — lekin uni repoga qo'ysangiz, keyingi yangi odamning birinchi kuni bir kun qisqaradi. Bundan tashqari, xaritani yozayotganda tushunmagan joylaringiz ochiladi: "bot nega API orqali emas?" — bu savol ro'yxatga tushadi.

Xarita kod emas — u eskiradi. Shuning uchun unda har detal emas, kam o'zgaradigan narsalar: jarayonlar, asosiy oqim, papkalar mas'uliyati. Funksiya nomlari va qatorlar soni — yo'q.

7. Birinchi vazifa

7.1 good first issue

Ko'p jamoalar yangi odamlar uchun maxsus yorliqli issue'larni tayyorlab qo'yadi — good first issue. GitHub hujjatiga ko'ra, ochiq repoda bu yorliqli issue'lar yorliq bo'yicha qidiruvda topiladi va GitHub ularni sayt bo'ylab yangi hissa qo'shuvchilarga ko'rsatishi mumkin (docs.github.com, 2026-11). Yaxshi birinchi vazifaning belgilari:

• kichik — bir-ikki kunlik ish;
• chegarasi aniq — qayerdan boshlash va qachon tugashi yozilgan;
• loyihaning muhim qismiga tegadi, lekin xavfli joyiga emas — masalan, migratsiya yoki auth emas;
• mavjud naqsh bor — shunga o'xshash kod loyihada allaqachon yozilgan.

7.2 Kanon issue'si

Kanon kurs sinov reposida bunday issue ochdi — github.com/Sarvarbek0704/ilmhamroh-git-sinov/issues/8 (repo arxivda, faqat o'qish uchun). Sarlavha: feat(ai): breaker holatini /metrics ga chiqarish. Yorliqlar: good first issue, tur: xususiyat, holat: tayyor, sp: 2. Tavsifi (aynan, uzun qatorlar bo'lindi; asl matndagi bo'lim raqami iqtibosda bo'lim nomi bilan almashtirildi):

**Nima:** `ChidamliProvayder` breaker holatini
(`yopiq` / `ochiq` / `yarim`) model bo'yicha Prometheus metrikasi
sifatida chiqarish — hozir faqat `hisob` obyekti bor.

**Qayerdan boshlash:** `vazifalar-api/src/ai/chidamli.ts`
(`holatModel()`), `vazifalar-api/src/kuzatuv/metrikalar.ts`
(`fonXatolari` — modul darajasidagi metrika namunasi),
`docs/ARXITEKTURA.md`, «Birinchi vazifa: qanday boshlash» bo'limi.

**Qabul mezonlari:**
- [ ] `/metrics` da `ai_breaker_holati{model="…"}`
  (0 — yopiq, 1 — yarim, 2 — ochiq)
- [ ] test: breaker ochilganda qiymat 2
- [ ] `npm run check` yashil

Taxmin: 2 SP. Savollar — shu issue'da.

Bu issue'da to'rtta belgining hammasi bor. U kichik: 2 story point (Estimatsiya darsida o'rganamiz, hozircha "nisbiy murakkablik bahosi" deb tushuning). Boshlash joyi aniq. Resilience naqshlari darsidagi breaker'ga tegadi. Va namuna ko'rsatilgan: fonXatolari metrikasi xuddi shunday yozilgan. Yangi odam noldan o'ylamaydi — mavjud naqshni takrorlaydi.

Bu issue kanonda ataylab ochiq qoldirildi: u — o'quvchi uchun.

7.3 Vazifani qanday boshlash

Kanon ARXITEKTURA.md dagi tartib (aynan, qatorlar bo'lindi):

1. Issue'lardan `good first issue` yorlig'idagisini oling, issue'da
   "men olaman" deb yozing (ikki kishi bir ishni qilmasin).
2. Avval **o'qing**: issue'da tilga olingan fayl va uning testi.
   `git log -p --follow <fayl>` — fayl qanday o'zgargan va nega.
3. Branch: `git switch -c fix/<qisqa-nom>` (`fix/`, `feat/`, `docs/`
   — commit turi bilan bir xil).
4. Avval yiqiladigan test, keyin kod. `npm run check`.
5. Kichik PR (≈ 200 qatordan kam), shablon bo'yicha tavsif. Savol
   tug'ilsa — PR'ni draft qilib oching va so'rang.

Ikkinchi qadamga e'tibor bering: kod yozishdan oldin — o'qish. «Git tarixi» bo'limidagi buyruqlar aynan shu yerda ishlaydi. 4-qadam — Bisect darsidagi "avval yiqiladigan test" odati. 5-qadamdagi PR hajmi va draft — keyingi darsning mavzusi.

8. Savollar ro'yxati

Yangi odam savol berishdan uyaladi: "men bilimsiz ko'rinaman". Aslida teskarisi: savol bermagan odam ikki kun adashadi, keyin baribir so'raydi. Kanon xaritasining oxirida birinchi hafta savollari bor:

Savollar ro'yxati (birinchi haftada so'rash odatiy): qaysi muhitlar
bor (lokal, staging, prod)? kim review qiladi? reliz qachon? qaysi
metrikaga qaraladi? "Bilmayman" — normal javob; yozib qo'yilmagan
bilim — hujjatga aylantirish uchun birinchi nomzod.

Ro'yxatni o'zingiz to'ldiring. Yaxshi savol uch qismdan iborat: nima qilmoqchisiz, nimani sinadingiz, qayerda to'xtadingiz. "Testlar ishlamayapti" — yomon savol. "npm run check da migratsiya.test 5 soniyada timeout beradi; Postgres 5432 da ishlayapti, .env dagi TEST_DATABASE_URL to'g'ri — yana nimani tekshiray?" — yaxshi savol. Bunday savolga hamkasb bir daqiqada javob beradi.

Javobni olganingizdan keyin — uni hujjatga qo'shing. Xaritadagi oxirgi gap shu haqida: "yozib qo'yilmagan bilim — birinchi nomzod". Yangi odamning birinchi PR'i ko'pincha hujjat tuzatishi bo'ladi, va bu juda yaxshi boshlanish.

9. Loyiha qadami: docs/ARXITEKTURA.md

Endi vazifalar-api ga o'z xaritangizni yozasiz. Branch — Jamoa workflow'lari qoidasi bilan:

git switch main
git pull
git switch -c docs/arxitektura

Kanon faylining tuzilmasi (101 qator):

Faylning boshi — kim uchun va nima uchun yozilgani (aynan):

# vazifalar-api — arxitektura xaritasi

Bu hujjat loyihaga yangi qo'shilgan dasturchi uchun. Maqsad —
birinchi kunda "nima qayerda" degan savolga javob berish va birinchi
kichik vazifani bir haftada emas, bir kunda tugatish.

Papkalar jadvalidan uch qator (kanon faylidan, uzun kataklar … bilan qisqartirildi):

| Papka | Mas'uliyat | Qaysi qismda paydo bo'lgan |
|---|---|---|
| `src/auth/` | sessiya, parol (argon2id), 2FA, … | 28, 30 |
| `src/ai/` | LLM provayder qatlami, …, chidamlilik | 31, 32 |
| `prisma/` | `schema.prisma`, migratsiyalar … | 27+ |

"Qaysi qismda paydo bo'lgan" ustuni — bizning kursga xos. Haqiqiy loyihada uning o'rnida "egasi" (jamoa yoki odam) ustuni bo'ladi — Git va monorepo darsidagi CODEOWNERS bilan bir xil ma'lumot.

Fayl tayyor bo'lgach — o'zingiz yozgan «Lokal ishga tushirish» bo'limi bo'yicha qadamlarni toza papkada bir marta takrorlang. Ishlamagan qadam — hujjat xatosi. Keyin commit:

git add docs/ARXITEKTURA.md
git commit -m "docs: arxitektura xaritasi va birinchi vazifa yo'riqnomasi"
git push

Kanon xabarini aynan oldik. push.autoSetupRemote yoqilgan bo'lsa (Git konfiguratsiyasi), -u shart emas. Keyin PR — kanonda bu sinov reposidagi PR #13: bitta fayl, +101 qator, squash bilan main ga tushdi.

O'z repo'ngizda yana bitta qadam: issue ochib, unga good first issue yorlig'ini qo'ying — masalan, kanondagidek breaker metrikasi. Uni keyinroq o'zingiz bajarasiz yoki kursdosh do'stingizga berasiz.

Kanon PR #13 ni ochishda GitHub'ning haqiqiy nosozligiga duch keldi. Birinchi push:

 ! [remote rejected] docs/arxitektura -> docs/arxitektura (Internal Server Error)

Darhol keyingi gh pr create:

pull request create failed: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between main and docs/arxitektura, Head ref must be a branch (createPullRequest)

"Branch topilmadi, main bilan orada commit yo'q." Xabar chalg'itadi: muammo commitda emas, push serverga yetib bormagan. 19 soniyadan keyin qayta push — * [new branch], PR yaratildi. Saboq Jamoa workflow'lari darsidagidek: xato kelsa, avval holatni tekshiring (git ls-remote origin docs/arxitektura), keyin xulosa qiling.

10. Ko'p uchraydigan xatolar

10.1 Hamma narsani o'qishga urinish

Bir hafta fayllarni ketma-ket o'qish — eng ko'p uchraydigan xato. Bilim mustahkamlanmaydi, chunki uni ishlatmaysiz. Yechim: xarita + bitta vazifa. Vazifa kerak bo'lgan joyni chuqur o'qiysiz, qolganini — yuzaki.

10.2 Lokal ishga tushirmasdan kod yozish

Testlarsiz o'zgarish — ko'r-ko'rona o'zgarish. PR'dagi CI xato beradi, siz esa sababini bilmaysiz. Birinchi kunning maqsadi — npm run check yashil.

10.3 Bir xil savolni ikki marta berish

Javobni yozib olmasangiz, ikki haftadan keyin yana so'raysiz. Eslatma fayl yuriting yoki — yaxshirog'i — javobni hujjatga PR bilan qo'shing.

10.4 Birinchi vazifa — juda katta

"Auth'ni qayta yozaman" — birinchi hafta uchun emas. Katta vazifa uzoq branch, katta PR va og'ir review degani. Agar sizga katta vazifa berilsa — uni kichik qismlarga bo'lishni so'rang (Estimatsiya va vazifani kichik qismlarga bo'lish darsida o'rganamiz).

10.5 shortlog ni baho sifatida o'qish

Commit soni — odamning qiymati emas. Bitta muhim xatoni topgan bitta commit yuzta mayda commitdan qimmatroq bo'lishi mumkin. shortlog — "kimdan so'rash" uchun, "kim yaxshi ishlaydi" uchun emas.

11. Mashqlar

Mashqlar kurs/mashqlar/32/09-kirish/ da. 2-mashq yechimi Node 24.21.0 da, 3-mashq yechimi Git 2.54.0 da tekshirilgan (biz ishga tushirdik).

1-mashq (oson): bo'shliqlarni to'ldiring

• Muallif bo'yicha commitlar sonini ko'rsatadigan buyruq — git -sn
• git log da sarlavhasiz, faqat fayl nomlarini chiqaradigan bayroq — --name-
• Matnni qo'shgan yoki olib tashlagan commitni topadigan bayroq — git log -
• GitHub'da yangi odamlar uchun kichik vazifa yorlig'i —
• Birinchi kunning maqsadi — shu buyruq yashil bo'lsin: npm run

2-mashq (o'rta): qaynoq fayllar funksiyasi

qaynoqFayllar(chiqish, n, tashla) funksiyasini yozing. Kirish — git log --format= --name-only ning to'liq matni (qatorlar orasida bo'sh qatorlar bor). Funksiya eng ko'p uchragan n ta faylni "son fayl" ko'rinishida qaytarsin; son teng bo'lsa — nom bo'yicha alifbo tartibida. tashla — e'tiborsiz qoldiriladigan fayllar massivi (masalan, package-lock.json). Ishora: matnni split("\n") bilan bo'ling (Kesish, bo'lish va to'ldirish), sanash uchun Map (Map), saralashda ikki shart (sort va taqqoslash funksiyasi).

function qaynoqFayllar(chiqish, n, tashla = []) {
  const son = new Map();
  for (const fayl of chiqish.split("\n")) {
    if (fayl === "" || tashla.includes(fayl)) continue;
    son.set(fayl, (son.get(fayl) ?? 0) + 1);
  }
  return [...son]
    .sort((a, b) => b[1] - a[1] || a[0].localeCompare(b[0]))
    .slice(0, n)
    .map(([fayl, k]) => `${k} ${fayl}`);
}

const chiqish = [
  "src/narx.js", "", "src/bron.js", "package-lock.json", "",
  "src/narx.js", "src/config.js", "", "package-lock.json",
  "src/narx.js", "", "src/bron.js", "",
].join("\n");
console.log(qaynoqFayllar(chiqish, 3));
console.log(qaynoqFayllar(chiqish, 3, ["package-lock.json"]));

[ '3 src/narx.js', '2 package-lock.json', '2 src/bron.js' ]
[ '3 src/narx.js', '2 src/bron.js', '1 src/config.js' ]

3-mashq (qiyin): uch savol, uch buyruq

begona-yarat.sh bilan o'quv loyihani yarating va faqat git buyruqlari bilan uch savolga javob bering:

1. src/bron.js ni kim eng ko'p o'zgartirgan?
2. "juma" ustamasi qaysi commitda paydo bo'lgan va uni kim yozgan?
3. docs/ papkasidagi birinchi fayl qachon va kim tomonidan qo'shilgan?

Ishora: bitta fayl bo'yicha shortlog; -S bilan pickaxe; --diff-filter=A — faqat fayl qo'shilgan (Added) commitlar.

bash begona-yarat.sh choyxona > /dev/null && cd choyxona
git shortlog -sn HEAD -- src/bron.js
git log -S"juma" --format='%h %an: %s'
git log --diff-filter=A --format='%ad %an: %s' --date=short \
  -- docs
cd .. && rm -rf choyxona

     3	Aziz Karimov
9ac748c Nodira Rahimova: feat(narx): juma kuni ustama
2026-09-28 Sardor Aliyev: docs: arxitektura qisqacha

12. Real ishda

• Qayerda uchraydi: ko'p kompaniyalarda yangi xodimga "onboarding buddy" — birinchi haftalarda savol beriladigan hamkasb biriktiriladi. Katta ochiq loyihalarda CONTRIBUTING.md va good first issue yorlig'i — yangi hissa qo'shuvchilarning asosiy kirish eshigi (Open source darsida).
• Birinchi PR — hujjat: yangi odam topgan eskirgan buyruq yoki noto'g'ri raqam — eng yaxshi birinchi PR. Kichik, xavfsiz va jamoaga darhol foyda.
• Intervyu savollari: "Yangi loyihaga kirganingizda birinchi haftada nima qilasiz?", "Notanish kod bazasini qanday o'rganasiz?", "Hujjatsiz loyihada birinchi qadamingiz?"

Xulosa

• Birinchi hafta tartibi: hujjatlar → lokal ishga tushirish (npm run check yashil) → xarita → tarix → kichik vazifa; savollar bitta ro'yxatda.
• Hujjat eskiradi: raqam va buyruqlarni o'zingiz tekshiring, farqni PR bilan tuzating.
• git shortlog -sn, qaynoq fayllar quvuri, git log -- <fayl> va -S — loyihaning kim, nima va nega xaritasi.
• Arxitektura xaritasi kirish nuqtalaridan boshlanadi: jarayonlar, bitta so'rov yo'li, papkalar mas'uliyati.
• Yaxshi good first issue — kichik, chegarasi aniq, namunasi bor; kanonda sinov reposidagi issue #8.

Keyingi dars: Yaxshi PR tayyorlash — kichik, tushunarli va tez review qilinadigan PR: hajm, sarlavha, PR shabloni, self-review, draft va stacked PR'lar.

Manbalar

• Git hujjati — git-shortlog: https://git-scm.com/docs/git-shortlog
• Git hujjati — git-log (--name-only, -S, --diff-filter): https://git-scm.com/docs/git-log
• GitHub Docs — Encouraging helpful contributions with good first issues: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels (sinalmagan, 2026-11)
• C4 model: https://c4model.com/ (sinalmagan, 2026-11)
• Kurs sinov reposi — issue #8 va PR #13: https://github.com/Sarvarbek0704/ilmhamroh-git-sinov/issues/8 (2026-11-04, gh issue view bilan o'qildi)
• Kanon tajribasi (IlmHamroh, 2026-11-04): docs/ARXITEKTURA.md (101 qator), PR #13 dagi GitHub nosozligi. O'quv loyiha buyruqlari, kanon tarixidagi qaynoq fayllar, kod hajmi sanog'i va mashq yechimlari — biz ishga tushirdik (2026-11-04).