Conventional Commits va commitlint: commit xabarini standartlash

Qisqacha: Conventional Commits — commit sarlavhasini tur(soha): tavsif shaklida yozish kelishuvi: feat: qidiruv maydoni, fix(api): 409 xatosi. Tur mashinaga "bu yangi imkoniyatmi, tuzatishmi?" deb aytadi — shundan changelog va versiya avtomatik yasaladi. commitlint esa xabarni shu qoidaga solishtiradi va noto'g'risini rad etadi.

Bu darsda

• Conventional Commits sarlavhasining qismlarini (type, scope, !, subject) o'qiy va yoza olasiz.
• feat, fix, chore va boshqa turlarni bir-biridan farqlaysiz.
• BREAKING CHANGE va ! nima uchun kerakligini, semver bilan bog'liqligini tushuntirasiz.
• commitlint ni o'rnatib, sozlab, terminalda va Git tarixida sinaysiz.
• Nega vazifalar da subject-case qoidasi o'chirilganini o'lchov bilan asoslaysiz.

Oldin bilishingiz kerak: Yaxshi commit: atomar commit va xabar yozish, Tag va relizlar, Semver va versiya diapazonlari.

1. Nega bu kerak?

Yaxshi commit darsida commit xabarini odam uchun yozishni o'rgandik: qisqa sarlavha, buyruq mayli, "soha: nima qilindi". Masalan, Menyu: osh narxini qo'sh. Odam buni yaxshi tushunadi.

Endi Jasur aka yangi talab qo'ydi: "Har relizda nima o'zgarganini mijozlarga yozib bering. Yangi imkoniyatlar alohida, tuzatishlar alohida". Sardor git log ni ochdi — 200 ta commit. Har birini o'qib, "bu yangi imkoniyatmi yoki tuzatishmi?" deb ajratish — bir soatlik ish. Har relizda.

Agar har commit o'zi "men yangi imkoniyatman" yoki "men tuzatishman" deb yozilsa, bu ishni dastur bajaradi. Bunga kelishilgan shakl kerak. Xuddi pochta manzili kabi: shahar, ko'cha, uy — doim bir tartibda. Shunda xatni har qanday pochtachi (yoki saralash mashinasi) yetkazadi.

Conventional Commits ("kelishilgan commitlar") — commit xabarini mashina ham o'qiy oladigan qilib yozish standarti (conventionalcommits.org, 1.0.0 versiyasi). 15-qismdan beri vazifalar commitlari aynan shunday yozilgan: chore: …, refactor: …. Bugun nega shunday ekanini bilib olamiz va qoidani asbobga topshiramiz.

2. Sarlavha anatomiyasi

2.1 Qismlar

feat(api)!: eksport formati v4

flowchart LR
  T["feat<br/>tur (type)"] --> S["(api)<br/>soha (scope)<br/>ixtiyoriy"]
  S --> B["!<br/>buzuvchi<br/>ixtiyoriy"]
  B --> D[": eksport formati v4<br/>tavsif (subject)"]

Tavsif sizning tilingizda bo'lishi mumkin — standart faqat tuzilmani belgilaydi. vazifalar da turlar inglizcha (standart nomlari), tavsif o'zbekcha.

2.2 Turlar

Standartning o'zi faqat ikki turni majburiy qiladi: feat va fix. Qolganlari — keng tarqalgan kelishuv (@commitlint/config-conventional ro'yxati):

Eng ko'p chalkashlik — refactor va chore orasida. Savol bering: "o'zgarish ilova kodidami?" Ha — refactor (yoki feat/fix). Yo'q, faqat asbob va sozlamada — chore.

Tekshirib ko'ring: Sardor render.ts dagi uzun funksiyani ikkiga bo'ldi. Sahifada hech narsa o'zgarmadi. Qaysi tur?

2.3 Tana va footer

Sarlavhadan keyin bo'sh qator, keyin tana — Yaxshi commit darsidagidek, "nega". Oxirida — footer (pastki qism): Kalit: qiymat shaklidagi qatorlar.

feat(api)!: eksport formati v4

v3 fayllari endi o'qilmaydi.

BREAKING CHANGE: paketniTekshir faqat versiya 4 ni qabul qiladi

BREAKING CHANGE: footer'i yoki sarlavhadagi ! — "bu o'zgarish eski foydalanuvchilarni buzadi". Ikkalasini birga yozish ham mumkin: ! ko'zga tez tashlanadi, footer esa nima buzilganini tushuntiradi.

3. Turdan versiyaga

3.1 Semver bilan bog'lanish

Tag va relizlar va Semver darslaridan MAJOR.MINOR.PATCH ni bilasiz. Conventional Commits aynan shunga mos keladi:

flowchart LR
  F["fix: …"] --> P["PATCH<br/>1.4.2 → 1.4.3"]
  E["feat: …"] --> M["MINOR<br/>1.4.2 → 1.5.0"]
  B["feat!: …<br/>BREAKING CHANGE"] --> J["MAJOR<br/>1.4.2 → 2.0.0"]
  C["chore, docs,<br/>refactor, test"] --> N["versiya<br/>o'zgarmaydi"]

Oxirgi relizdan beri faqat fix lar bo'lsa — PATCH. Kamida bitta feat — MINOR. Bitta BREAKING CHANGE — MAJOR. Shu qoida bilan dastur keyingi versiyani o'zi hisoblaydi va CHANGELOG yozadi: "Yangi imkoniyatlar" bo'limiga feat lar, "Tuzatishlar" ga fix lar.

Buni bajaradigan vositalar (release-please, semantic-release, changesets) — CHANGELOG va reliz avtomatikasi darsida. vazifalar — sayt, npm paketi emas: unda versiya raqamlari yo'q (package.json pasporti). Lekin tarix baribir o'qilishi oson bo'ladi.

Tekshirib ko'ring: Oxirgi reliz 2.3.1. Shundan beri uch commit: docs: README, fix(sw): oflayn sahifa, feat: tema tanlash. Keyingi versiya qanday?

4. commitlint

4.1 Asbob nima qiladi

Kelishuvni odamlar unutadi. commitlint — commit xabarini qoidalar ro'yxatiga solishtiradigan dastur. U ESLint ning xabarlar uchun varianti: qoidalar, darajalar va tayyor to'plamlar (extends) bor.

Ikki paket kerak:

• @commitlint/cli — dasturning o'zi (npx commitlint);
• @commitlint/config-conventional — Conventional Commits qoidalari to'plami.

4.2 Vazifalar qadami: o'rnatish

Branch: chore/commitlint.

npm i -D -E @commitlint/cli@21.2.3 \
  @commitlint/config-conventional@21.2.3

added 56 packages, and audited 200 packages in 12s

69 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Ikki paket — 56 ta yangi paket (ular olib kelgan bog'liqliklar bilan). -E sizda kerak emas: vazifalar ning .npmrc faylida save-exact=true bor (Ta'minot zanjiri). Versiya — 2026-10 holatiga eng yangisi.

Ildizda commitlint.config.js:

// commitlint.config.js — commit xabari qoidalari (16/#40,
// Conventional Commits): "tur: qisqa tavsif" — feat, fix, refactor,
// chore, docs, test... Tavsif o'zbekcha, tur nomlari —
// standartdagidek inglizcha
export default {
  extends: ["@commitlint/config-conventional"],
  rules: {
    // Sarlavha ≤ 72 belgi (kanon 2.4: git log --oneline va GitHub'da
    // kesilmaydi); config-conventional da 100
    "header-max-length": [2, "always", 72],
    // Tavsif katta harf bilan boshlanmasin — inglizcha uchun yaxshi,
    // bizda esa nom bilan boshlanadi: "ESLint ...", "PWA ...",
    // "Natija (Result) ..." (12–15-qism commit'larining 7 tasi shu
    // qoida bilan yiqildi — o'lchandi). O'chiramiz
    "subject-case": [0],
  },
};

4.3 Qoida yozuvi: uch qism

ESLint'da qoida "error" yoki ["error", {…}] edi. commitlint'da doim massiv:

[2, "always", 72] — "xato darajasida, doim, 72 dan oshmasin". [0] — butunlay o'chiq, qolgan qismlar kerak emas.

4.4 Terminalda sinash

commitlint matnni standart kirishdan o'qiydi. echo bilan unga xabar beramiz (quvur — |):

echo "Vite qo'shildi" | npx commitlint

commitlint chiqishini o'qish oson: input — tekshirilgan xabar, ✖ bilan boshlangan har qator — bitta buzilgan qoida (qoida nomi oxirida, kvadrat qavsda).

⧗   --- input ---
Vite qo'shildi
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

"Tavsif bo'sh bo'lmasin", "tur bo'sh bo'lmasin". Kutilmagan so'zlar: tavsif-ku bor! Lekin commitlint tur: shaklini topa olmadi va butun xabarni tanimadi. Shuning uchun ikkala qism ham "bo'sh". Qavs ichida — qoida nomi. Chiqish kodi 1.

Ikki nuqtadan keyin bo'sh joyni unutsangiz ham xuddi shu xato:

echo "feat:Vite qo'shildi" | npx commitlint

⧗   --- input ---
feat:Vite qo'shildi
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Katta harfli tur:

echo "Feat: vite bilan build" | npx commitlint

⧗   --- input ---
Feat: vite bilan build
✖   type must be lower-case [type-case]
✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

"Tur kichik harfda bo'lsin" va "tur shu ro'yxatdan bo'lsin". Ruxsat etilgan 11 tur — shu xabarning o'zida. Uzun sarlavha:

m="build: vite bilan build — tsc emit o'rniga, public/ va qobiq"
m="$m skripti, blocking=render plagini"
echo "$m" | npx commitlint

⧗   --- input ---
build: vite bilan build — tsc emit o'rniga, public/ va qobiq skripti, blocking=render plagini
✖   header must not be longer than 72 characters, current length is 93 [header-max-length]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

"Sarlavha 72 belgidan oshmasin, hozir 93". Bu bizning qoidamiz. To'g'ri yechim — uzun qismni tanaga: git commit -m "sarlavha" -m "tana" (Yaxshi commit).

To'g'ri xabarlar esa jim o'tadi (chiqish yo'q, chiqish kodi 0) — bu muvaffaqiyat belgisi: feat(api): vazifalarni serverdan olish, feat!: eksport formati v4, fix: taymer to'xtamaydi.

4.5 Footer qoidasi: bo'sh qator

feat: eksport formati v4
BREAKING CHANGE: v3 fayllari o'qilmaydi

Footer sarlavhaga yopishib qoldi. commitlint:

⚠   footer must have leading blank line [footer-leading-blank]

⚠   found 0 problems, 1 warnings

"Footer oldida bo'sh qator bo'lsin". ⚠ — ogohlantirish (daraja 1), chiqish kodi 0. Bo'sh qator qo'shilsa — jim. Bo'sh qatorsiz reliz vositalari BREAKING CHANGE ni footer deb tanimasligi mumkin, keyin MAJOR versiya oshmay qoladi.

5. subject-case: nega o'chirdik

5.1 Sukutdagi xulq

config-conventional ning subject-case qoidasi tavsifni katta harf bilan boshlashni taqiqlaydi. Sozlamamizsiz (faqat extends bilan):

⧗   --- input ---
feat: Vite
✖   subject must not be sentence-case, start-case, pascal-case [subject-case]

⧗   --- input ---
chore: ESLint (flat config) va Prettier
✖   subject must not be sentence-case [subject-case]

"Tavsif gap kabi (birinchi harf katta) yozilmasin". Inglizcha uchun bu mantiqli: feat: add search, Add emas. Lekin bizning tavsiflar ko'pincha nom bilan boshlanadi: Vite, ESLint, PWA, README. Nomni kichik harf bilan yozish (eslint, pwa) — xato yozuv.

5.2 O'lchov

Taxmin qilmasdan, 12–15-qism vazifalar commitlarining 23 ta sarlavhasini sukutdagi to'plam (va 72 belgi chegarasi) bilan tekshirdik:

10 tadan 7 tasi — faqat subject-case: chore: ESLint (flat config) …, feat: PWA — …, refactor: Natija (Result) turi, …. Qolgan 3 tasi — 12-qismdagi 94–106 belgili uzun sarlavhalar; ular haqiqatan qoidaga zid.

Qaror: "subject-case": [0]. Qoida bizning tilimizga mos emas, foydasidan zarari ko'p. 16-qismning 18 ta commit sarlavhasi (37–71 belgi) yangi sozlama bilan hammasi o'tadi.

Maslahat: Qoidani o'chirish — mag'lubiyat emas. Muhimi — sababni config faylning o'zida izoh bilan yozish. Bir yildan keyin kimdir "nega o'chiq?" deb so'rasa, javob shu yerda turadi.

6. Tarixni tekshirish

commitlint faqat yangi xabarni emas, mavjud tarixni ham tekshiradi. Sinov repoda to'rt commit qildik, uchinchisi eski uslubda:

npx commitlint --from HEAD~3 --to HEAD

⧗   --- input ---
Menyu: osh narxini qo'sh
✖   type must be lower-case [type-case]
✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Qiziq natija: Menyu: osh narxini qo'sh ni commitlint tur: tavsif deb o'qidi — Menyu ni tur deb. 07-qismdagi "Soha: buyruq" shaklimiz tashqi ko'rinishda Conventional Commits'ga juda yaqin. Farqi: tur — belgilangan ro'yxatdan, soha esa qavsga o'tadi: feat(menyu): osh narxini qo'sh.

--from HEAD~3 uchta commitni tekshirdi (HEAD~3 ning o'zi kirmaydi). CI'da PR'dagi hamma commitni tekshirish shunday qilinadi.

Tekshirib ko'ring: --from bilan eski commit xatosi topildi. Uni qanday tuzatasiz?

7. Squash merge va PR sarlavhasi

Pull Request darsida birlashtirishning uch usulini ko'rgansiz. vazifalar da gh pr merge --merge ishlatamiz: branch'dagi commitlar main ga o'zgarishsiz tushadi, demak, har commit xabari muhim.

Ko'p jamoalar esa squash merge qiladi: PR'dagi hamma commit bittaga siqiladi. Bunda yangi commitning sarlavhasi odatda PR sarlavhasidan olinadi. Ichkaridagi "tuzatdim", "yana tuzatdim" kabi commitlar tarixga tushmaydi. Natija: commitlint'ni har commitda emas, PR sarlavhasida tekshirish kifoya. Buning uchun GitHub Actions'da alohida qadam yoziladi: PR sarlavhasi echo orqali npx commitlint ga beriladi.

Qaysi usul yaxshi? Bitta to'g'ri javob yo'q:

Footer'ning yana bir keng tarqalgan ishlatilishi — vazifa raqami: Refs: #42 yoki Closes: #42. GitHub Closes #42 ni ko'rsa, PR birlashganda 42-issue'ni o'zi yopadi (Issues). Bekor qilish commitlari esa shunday ko'rinadi: revert: feat: tema tanlash — git revert o'zi yozgan Revert "…" sarlavhasini shu shaklga keltirish kerak bo'ladi.

Tekshirib ko'ring: Jamoa squash merge ishlatadi. Dasturchi PR ichida wip, tuzatish, yana degan commitlar qildi. commitlint Git hook'i ularni rad etishi kerakmi?

8. Ko'p uchraydigan xatolar

Yana biri — config fayl topilmaydi. vazifalar da "type": "module", shuning uchun commitlint.config.js dagi export default ishlaydi. CommonJS loyihada bu fayl .mjs bo'lishi kerak (package.json pasporti).

9. Mashqlar

Mashq papkasi: kurs/mashqlar/16/40-commitlint/ — npm init -y, npm pkg set type=module, npm i -D -E @commitlint/cli@21.2.3 @commitlint/config-conventional@21.2.3. commitlint.config.js ni vazifalar dan nusxalang.

1-mashq (oson): o'tadimi?

Har sarlavha uchun o'tadi yoki yiqiladi yozing, keyin echo "…" | npx commitlint bilan tekshiring.

• feat: qidiruv maydoni —
• Feat: qidiruv —
• feat qidiruv —
• fix(api): 409 xatosi —
• refactor!: Vazifa klassi —
• yangilandi —

2-mashq (o'rta): sohalar ro'yxati

Jamoa kelishdi: soha faqat api, render, sw, tema bo'lishi mumkin. scope-enum qoidasini qo'shing (yozuvi header-max-length ga o'xshaydi, qiymati — ro'yxat). Tekshiring: feat(api): vazifalarni sahifalab olish, feat(menyu): narxlar, fix: taymer.

// 2-mashq yechimi: kanon qoidalari + ruxsat etilgan sohalar (scope)
export default {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "header-max-length": [2, "always", 72],
    "subject-case": [0],
    // Soha faqat shu ro'yxatdan: feat(api): ..., fix(sw): ...
    "scope-enum": [2, "always", ["api", "render", "sw", "tema"]],
  },
};

⧗   --- input ---
feat(menyu): narxlar
✖   scope must be one of [api, render, sw, tema] [scope-enum]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

3-mashq (o'rta): buzuvchi o'zgarish

paketniTekshir endi faqat 4-versiya eksportini qabul qiladi deb tasavvur qiling. Shunday commit xabarini yozingki: soha — api, sarlavhada buzuvchi belgi, tanada sabab, footer'da nima buzilgani. printf '%s\n' bilan commitlint'ga bering: u har argumentni alohida qatorga yozadi, "" esa bo'sh qator beradi.

printf '%s\n' "feat(api)!: eksport formati v4" "" \
  "v3 fayllari endi o'qilmaydi." "" \
  "BREAKING CHANGE: paketniTekshir faqat v4 ni qabul qiladi" \
  | npx commitlint

4-mashq (qiyin): Vazifalar qadami

kurs/vazifalar da:

1. git switch -c chore/commitlint, paketlarni o'rnating va commitlint.config.js ni yarating («Vazifalar qadami: o'rnatish» bo'limi).
2. npx commitlint --from HEAD~10 --to HEAD — oxirgi 10 commit qoidaga mosmi?
3. subject-case qatorini vaqtincha o'chirib (izohga olib), 2-qadamni takrorlang. Nechta yiqildi?
4. Qatorni qaytaring, npm run check, commit: chore: commitlint — Conventional Commits, sarlavha ≤ 72 belgi.

10. Real ishda

• Ochiq kodli loyihalar — Angular, Vite, Vue, Electron — Conventional Commits'dan foydalanadi; ularning CHANGELOG'i commitlardan yasaladi.
• Kompaniyalarda PR sarlavhasi ham shu shaklda tekshiriladi (squash merge'da u commit sarlavhasiga aylanadi).
• Jira/vazifa raqami ko'pincha footer'da: Refs: VAZ-142.
• Intervyu: "feat va fix versiyaga qanday ta'sir qiladi?", "BREAKING CHANGE qanday belgilanadi?", "commitlint qayerda ishga tushadi?".

Xulosa

• Sarlavha: tur(soha)!: tavsif; tur — ro'yxatdan (feat, fix, refactor, chore, docs, test, build…), soha va ! — ixtiyoriy.
• fix → PATCH, feat → MINOR, ! yoki BREAKING CHANGE: → MAJOR; shundan changelog va versiya avtomatik yasaladi.
• commitlint — xabarlar uchun linter: extends + rules, qoida — [daraja, "always"/"never", qiymat].
• vazifalar: header-max-length: 72, subject-case: [0] — o'zbekcha tavsif nom bilan boshlanadi (o'lchov: 23 tadan 7 tasi faqat shu qoidaga urildi).
• echo "…" | npx commitlint — sinash; --from/--to — tarix; --edit — Git hook ichida.

Keyingi dars: Git hooklar: Husky va lint-staged — commitlint, ESLint va Prettier'ni har git commit da avtomatik ishga tushiramiz; faqat o'zgargan fayllar tekshiriladi.

Manbalar

• Conventional Commits 1.0.0 — standart matni
• commitlint: Getting started, Rules reference, config-conventional
• Semantic Versioning 2.0.0