4.5-bob: Conventional commits va .gitignore

4-QISM — Git va hamkorlik · 5-mavzu (yakuniy)

1. Kirish va motivatsiya

Git asoslari 4.1-bob, branch 4.2-bob, GitHub 4.3-bob va workflow 4.4-bob ni bildik. Endi 4-QISMni ikki muhim, amaliy detal bilan yakunlaymiz:

1. Conventional Commits — commit xabarlarining standarti. 4.1-bobda "mazmunli xabar yoz" dedik; endi uning rasmiy formati — bu nafaqat o'qishni osonlashtiradi, balki avtomatlashtirishga (versiya, changelog) imkon beradi.
2. .gitignore — qaysi fayllarni Git butunlay e'tiborsiz qoldirish (node_modules, .env, build). 0.7-bobda eslatdik; endi to'liq ochamiz.

O'xshatish (conventional commits): commit xabari — kitobning mundarijasi. "asd", "tuzatish" — mundarija o'rniga bo'sh sahifa. feat: login qo'shildi — aniq, qidiriladigan, avtomatik tushuniladigan yozuv. Standart format — kompyuter ham, odam ham o'qiy oladi.

O'xshatish (.gitignore): uy ko'chayotganda hamma narsani olib ketmaysiz — axlatni, vaqtinchalik narsalarni tashlaysiz. .gitignore — "bularni Git'ga olma" ro'yxati: node_modules (qayta o'rnatiladi), .env (maxfiy), build (qayta yaratiladi).

Nega muhim?

• Conventional commits — toza tarix, avtomatik changelog/versiya (semantic-release), jamoa standarti.
• .gitignore — maxfiy ma'lumotni himoya (14), repo'ni toza/yengil tutish.
• Professional loyihaning belgisi; 4-QISMni amaliy yakunlaydi.

2. Nazariya — chuqur tushuntirish

2.1. Conventional Commits nima?

Conventional Commits — commit xabari uchun yengil standart (conventionalcommits.org). Format:

  <tur>(<doira>): <tavsif>

  [ixtiyoriy tana]

  [ixtiyoriy footer]

Misol:

feat(auth): login formasiga email validatsiyasi qo'shildi

Email format RegEx bilan tekshiriladi 2.13-bob.
Bo'sh yoki noto'g'ri email rad etiladi.

Closes #42

2.2. Commit turlari (type)

Asosiy turlar (conventionalcommits.org):

git commit -m "feat: savatga qo'shish tugmasi"
git commit -m "fix: narx hisobida 0 ga bo'lish xatosi tuzatildi"
git commit -m "docs: README'ga o'rnatish bo'limi qo'shildi"
git commit -m "refactor(api): so'rov logikasi service'ga ajratildi"

2.3. Doira (scope) — ixtiyoriy

Scope — o'zgarish qaysi qismga tegishli (qavs ichida):

  feat(auth): ...       autentifikatsiya qismi
  fix(cart): ...        savat qismi
  style(navbar): ...    navbar

Scope — loyiha modullariga (auth, cart, api, ui) mos. Ixtiyoriy, lekin foydali (qidirish/filtrlash oson).

2.4. Breaking change — muhim o'zgarish

Orqaga mos kelmaydigan o'zgarish (eski kodni buzadi — 0.7: semver MAJOR) ! yoki BREAKING CHANGE: bilan belgilanadi:

feat(api)!: javob formati o'zgartirildi

BREAKING CHANGE: /users endpoint endi {data, meta} qaytaradi,
oldingi tekis massiv o'rniga. Frontend yangilanishi kerak.

Bu — semver 0.7-bob ga bog'lanadi: fix PATCH, feat MINOR, breaking MAJOR. Avtomatik versiyalash shunga tayanadi 2.6-bob.

2.5. Nega conventional commits?

• O'qishli tarix — git log --oneline aniq, qidiriladigan.
• Avtomatik changelog — vositalar (standard-version, semantic-release) commit'lardan o'zgarishlar ro'yxatini yaratadi.
• Avtomatik versiya — fix/feat/breaking PATCH/MINOR/MAJOR (semver — 0.7).
• Jamoa standarti — har kim bir xil formatda yozadi 4.4-bob.
• CI/CD — commit turidan reliz qarorlari 10.5-bob.

2.6. Avtomatlashtirish vositalari (qisqacha)

• Commitlint — commit xabarini standartga tekshiradi (Husky bilan — 15.3).
• standard-version / semantic-release — commit'lardan avtomatik versiya + changelog.
• Husky 15.3-bob — git hook'lar (commit'dan oldin lint/test).

Git hook'lar — Git muayyan harakatda avtomatik ishga tushiradigan skriptlar. Conventional Commits uchun ikkitasi muhim: commit-msg (commit xabari yozilgach ishlaydi — commitlint shu yerda formatni tekshiradi, noto'g'ri bo'lsa commit'ni rad etadi) va pre-commit (commit'dan oldin ishlaydi — lint/test/format). Husky bu hook'larni sozlashni osonlashtiradi.

Bularni 15.3-bobda chuqur ko'ramiz; hozir g'oyani bilish kifoya.

2.7. .gitignore nima va nega?

.gitignore — Git butunlay e'tiborsiz qoldiradigan fayllar/papkalar ro'yxati (0.2: yashirin fayl). Repo ildizidagi .gitignore faylga yoziladi:

  node_modules/       npm qayta o'rnatadi 0.7-bob — git'ga shart emas
  .env                MAXFIY (parol, kalit — 14) — HECH QACHON git'ga
  dist/  build/       qayta yaratiladi (build natijasi)
  *.log               log fayllar
  .DS_Store           macOS tizim fayli

2.8. Nega bu fayllarni e'tiborsiz qoldiramiz?

• node_modules/ — minglab fayl, juda katta; package.jsondan qayta tiklanadi (npm install — 0.7). Git'ga qo'yish — repo'ni shishiradi.
• .env — maxfiy ma'lumot (DB parol, API kalit — 14). Git'ga tushsa — hammaga ochiq (xavfsizlik falokati). Eng muhim qoida.
• build/dist/ — qayta yaratiladigan (manba'dan). Saqlash keraksiz.
• Tizim/IDE fayllari — .DS_Store, .vscode/ (shaxsiy) — loyihaga taalluqsiz.

2.9. .gitignore sintaksisi

node_modules/      # papka (oxirida /)
*.log              # naqsh — barcha .log fayllar (2.13: glob)
.env               # aniq fayl
.env.*             # .env.local, .env.prod...
!.env.example      # ! — ISTISNO (buni KUZAT — namuna sifatida)
build/             # papka
/temp              # faqat ildizdagi temp (boshida /)
**/*.tmp           # istalgan chuqurlikda .tmp

.env.example: haqiqiy .env (maxfiy) ignore qilinadi, lekin .env.example (kalitsiz namuna — qaysi o'zgaruvchilar kerakligini ko'rsatadi) kuzatiladi (! bilan). Bu — jamoaga yordam.

.gitattributes — qatorlar oxiri va atributlar

.gitignore qaysi fayllar kuzatilishini boshqarsa, .gitattributes track qilingan fayllar qanday ishlanishini belgilaydi. Eng keng tarqalgan vazifasi — qator oxiri (line ending) muammosini hal qilish: Windows CRLF, Linux/macOS LF ishlatadi, shuning uchun aralash jamoada bir xil fayl "o'zgargan"dek ko'rinib, keraksiz diff hosil qiladi 0.2-bob. .gitattributes buni bir joyda normallashtiradi:

* text=auto              # Git qator oxirini avtomatik normallashtiradi (repo'da LF)
*.sh text eol=lf         # shell skript doim LF
*.png binary             # rasm — binar, diff qilinmaydi

Bu fayl ham .gitignore kabi repo ildiziga qo'yiladi va commit qilinadi — jamoa sozlamasini bir xil tutadi. Boshlovchi loyihada * text=auto bitta qatori ko'pincha kifoya.

2.10. Allaqachon track qilingan faylni ignore qilish

.gitignore faqat hali track qilinmagan fayllarga ta'sir qiladi. Agar fayl allaqachon commit qilingan bo'lsa, avval Git'dan olib tashlash kerak:

# .env allaqachon commit qilingan, endi ignore qilmoqchimiz
git rm --cached .env          # Git'dan ol (lokal fayl QOLADI)
echo ".env" >> .gitignore     # ignore'ga qo'sh
git commit -m "chore: .env gitignore'ga qo'shildi"

Agar maxfiy ma'lumot allaqachon push qilingan bo'lsa — uni .gitignore yetarli emas (tarixda qoladi). Kalitni bekor qilib, yangisini yarating (14). Tarixdan tozalash murakkab (git filter-repo).

3. Sintaksis — tez ma'lumotnoma

CONVENTIONAL COMMITS:  <tur>(<scope>): <tavsif>
  feat | fix | docs | style | refactor | test | chore | perf
  feat(auth): login qo'shildi
  fix: narx xatosi tuzatildi
  feat!: BREAKING CHANGE (semver MAJOR — 0.7)

.GITIGNORE:
  node_modules/   .env   .env.*   !.env.example   dist/   *.log   .DS_Store
  git rm --cached <fayl>   # allaqachon track qilinganni olib tashlash

4. Batafsil amaliy namunalar

Misol 1 — Conventional commit'lar (2.2, 2.3)

# Yangi imkoniyat
git commit -m "feat(cart): savatga mahsulot qo'shish funksiyasi"

# Xato tuzatish (doira bilan)
git commit -m "fix(auth): token muddati noto'g'ri hisoblanishi tuzatildi"

# Hujjat
git commit -m "docs: API endpoint'lari hujjatlandi"

# Refactor (15.1)
git commit -m "refactor(api): takroriy so'rov logikasi util'ga ajratildi"

# Texnik ish
git commit -m "chore: eslint va prettier qo'shildi"

# Tana bilan (batafsil)
git commit -m "feat(search): real-time qidiruv

Har harf yozilganda debounce (300ms) bilan qidiradi 2.11-bob.
TanStack Query bilan cache'lanadi 12.4-bob.

Closes #28"

Misol 2 — Breaking change (2.4)

git commit -m "feat(api)!: /users javob formati o'zgartirildi

BREAKING CHANGE: endi {data: [...], meta: {...}} qaytariladi.
Frontend res.data.data sifatida o'qishi kerak.

Closes #55"
# Bu — semver MAJOR oshiradi (1.x.x  2.0.0 — 0.7)

Misol 3 — .gitignore (Node loyiha — 2.7, 2.9)

# .gitignore (Node.js loyiha uchun namuna)

# Dependencies 0.7-bob
node_modules/

# Maxfiy (14) — ENG MUHIM
.env
.env.local
.env.*.local
!.env.example          # namuna — kuzatiladi 2.9-bob

# Build natijalari
dist/
build/
.next/                 # Next.js (13)

# Loglar
*.log
npm-debug.log*

# IDE / OS
.vscode/
.DS_Store
Thumbs.db

# Test
coverage/              # test qamrovi (8.11)

Misol 4 — Track qilingan faylni tuzatish (2.10)

# Voy! .env tasodifan commit qilingan
git rm --cached .env                    # Git'dan ol (fayl lokal qoladi)
echo ".env" >> .gitignore               # ignore'ga
git add .gitignore
git commit -m "chore: .env xavfsizlik uchun gitignore'ga qo'shildi"

#  Agar PUSH qilingan bo'lsa — kalitlarni DARROV bekor qil (14)
# .gitignore tarixdagi maxfiy ma'lumotni o'chirmaydi!

5. To'g'ri va noto'g'ri holatlar

1) Mazmunsiz commit (standart o'rniga)

#  tushunarsiz, qidirib bo'lmaydi (4.1)
git commit -m "update"
git commit -m "fixed stuff"

#  conventional
git commit -m "fix(cart): jami summa hisobida yaxlitlash xatosi"

2) .envni git'ga qo'shish

#  maxfiy ma'lumot ochiq (14, xavfsizlik falokati)
git add .env && git commit -m "config"

#  .gitignore'da .env; .env.example (kalitsiz) kuzatiladi (2.9)

3) node_modules'ni commit qilish

#  minglab fayl, repo shishadi (2.8)
git add node_modules/

#  .gitignore'da node_modules/; npm install bilan tiklanadi

4) Loyiha boshida .gitignore yo'q

 birinchi commit'da .env/node_modules ham ketadi
 .gitignore — BIRINCHI commit'dan oldin yarat (0.7)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — node_modules allaqachon commit qilingan

Sababi: .gitignore kech qo'shildi (2.10, 4-holat). Yechimi: git rm -r --cached node_modules + .gitignore + commit.

Xato 2 — .env push qilindi (kalitlar ochiq)

Sababi: .gitignore yo'q edi (2.8, 14). Yechimi: kalitlarni darrov bekor qiling, yangisini yarating; .gitignorega qo'shing 2.10-bob.

Xato 3 — .gitignore ishlamayapti (fayl baribir track'da)

Sababi: fayl allaqachon track qilingan (.gitignore faqat yangi fayllarga — 2.10). Yechimi: git rm --cached <fayl>.

Xato 4 — Commit standartga mos emas (CI rad etadi)

Sababi: commitlint qoidasi 2.6-bob. Yechimi: to'g'ri format (feat:, fix:); git commit --amend 4.1-bob bilan tuzating.

Xato 5 — .env.exampleni ham ignore qildi

Sababi: .env* naqshi 2.9-bob. Yechimi: !.env.example (istisno) qo'shing.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• Git asoslari 4.1-bob: commit xabari standarti.
• Workflow 4.4-bob: jamoa commit konvensiyasi.
• Semver 0.7-bob: fix/feat/breaking PATCH/MINOR/MAJOR.
• Husky/Commitlint 15.3-bob: commit'ni avtomatik tekshirish (git hook).
• CI/CD 10.5-bob: commit turidan changelog/reliz.
• Xavfsizlik (14): .env himoyasi — eng muhim.
• dotenv 5.8-bob: .env — environment variables.
• Build (10, 13): dist/.next ignore.

8. Eng yaxshi amaliyotlar (best practices)

• Conventional commits ishlating — tur(scope): tavsif (2.1, 2.2).
• Commit — bitta mantiqiy o'zgarish 4.1-bob + aniq tur.
• .gitignoreni birinchi commit'dan oldin yarating (0.7, 4-holat).
• .envni hech qachon commit qilmang — eng muhim qoida (2.8, 14).
• .env.example (kalitsiz namuna) qo'shing — jamoaga yo'riqnoma 2.9-bob.
• node_modules/dist/build — doim ignore 2.8-bob.
• Breaking change'ni belgilang (!/BREAKING CHANGE — semver — 2.4).
• Maxfiy ma'lumot push qilinsa — kalitni bekor qil (.gitignore yetmaydi — 2.10).
• Til tanlovi izchil — jamoa ingliz yoki o'zbek commit'ni kelishsin.

9. Amaliy loyiha: "Professional Git Sozlamasi"

Conventional commits va .gitignore'ni amalda mustahkamlash — 4-QISMni yakunlaydi.

Maqsad

Conventional commit standartini va to'g'ri .gitignoreni qo'llab, professional, xavfsiz, toza Git loyihasi yaratish.

Talablar (requirements)

1. .gitignore: Node loyiha uchun to'liq (node_modules, .env, dist, log, IDE/OS — Misol 3); !.env.example istisno 2.9-bob.
2. .env.example: kalitsiz namuna (qaysi o'zgaruvchilar kerakligini ko'rsatadi).
3. Conventional commits: loyihani qurishda har xil turdagi kamida 6 commit: feat, fix, docs, refactor, chore, style (Misol 1, 2.2).
4. Scope: kamida 3 commit doira (scope) bilan (feat(auth): — 2.3).
5. Breaking change: kamida bitta feat!/BREAKING CHANGE (Misol 2, 2.4).
6. Track tuzatish: ataylab .envni commit qilib, keyin git rm --cached bilan tuzating (Misol 4, 2.10).
7. Tarix: git log --oneline — aniq, conventional tarix ko'rinsin.
8. (Bonus) Commit'lardan qo'lda CHANGELOG.md yozing (feat/fix bo'yicha guruhlangan — 2.5).

Maslahatlar (hint)

• .gitignore — birinchi commit'dan oldin (4-holat).
• Tur tanlovi: yangi feat, tuzatish fix, hujjat docs 2.2-bob.
• Scope — modul nomi (auth, cart, ui — 2.3).
• Breaking: feat!: yoki tanada BREAKING CHANGE: 2.4-bob.
• git rm --cached .env — fayl lokal qoladi 2.10-bob.
• .envni HECH QACHON haqiqiy kalitlar bilan commit qilmang (14).

"Tayyor" mezonlari (acceptance criteria)

• To'liq .gitignore (node_modules, .env, dist, log) + .env.example istisno.
• .env.example kalitsiz namuna sifatida bor.
• Kamida 6 commit, har xil conventional turlar.
• Kamida 3 commit scope bilan.
• Kamida bitta breaking change belgilangan.
• .env track'dan to'g'ri olib tashlangan (rm --cached).
• git log --oneline toza, conventional tarix ko'rsatadi.
• Maxfiy ma'lumot repo'da yo'q.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa — 4-QISM yakunlandi!

Bu bobda Git'ni professional qiladigan ikki detalni o'rgandik:

• Conventional Commits — tur(scope): tavsif standarti; turlar: feat, fix, docs, style, refactor, test, chore, perf. Breaking change (!) — semver MAJOR. Toza tarix + avtomatik changelog/versiya.
• .gitignore — Git e'tiborsiz qoldiradigan fayllar: node_modules (tiklanadi), .env (maxfiy — eng muhim!), build, log. .env.example (!) kuzatiladi.
• Allaqachon track qilingan: git rm --cached; push qilingan maxfiy ma'lumot — kalitni bekor qil.

4-QISM (Git va hamkorlik) — to'liq yakunlandi! (5 bob)

Siz endi bilasiz: Git asoslari, branch/merge/rebase, GitHub/PR/fork, workflow'lar, conventional commits va .gitignore. Bu — har bir professional loyiha va jamoaviy ishning poydevori.

Keyingi bob — 5.1-bob: Node.js kirish — runtime, event loop, V8. 5-QISM (Node.js Backend) boshlanadi — kitobning eng katta amaliy qismlaridan biri (23 bob). JavaScript'ni (2-qism) endi serverda ishlatamiz: 0.5-bobda ko'rgan V8 va event loop'ni chuqur ochib, real backend qurishni boshlaymiz.

Foydalanilgan rasmiy/ishonchli manbalar

• conventionalcommits.org — Conventional Commits v1.0.0 spetsifikatsiyasi
• git-scm.com — gitignore, git rm --cached
• semver.org — semantic versioning (commit turi bilan bog'liq)