Git: branch himoyasi, CODEOWNERS va PR shablonlari

Bu darsda uchta muhim jamoaviy ish vositasi ko'rib chiqiladi:

1. Branch Protection Rules — asosiy branchni tasodifiy yoki ruxsatsiz o'zgarishlardan himoya qilish
2. CODEOWNERS — PR-ni kim tasdiqlashi kerakligini belgilash
3. PR shabloni — barcha muhandislar bir xil formatda PR tavsifi yozishini ta'minlash

1. Branch Protection Rules

main branch — loyihaning asosiy, ishlab chiqarishga tayyor versiyasi. Agar ushbu branchning tarixi buzilsa, butun repo ham ta'sirlanishi mumkin. Shuning uchun main-ga o'zgarish kiritish qat'iy qoidalar bilan himoyalanishi kerak.

Qoidalarni qo'shish

GitHub-da: Repo → Settings → Branches → Add branch protection rule

Branch name pattern-ga main kiritiladi. Quyidagi parametrlar tavsiya etiladi:

Tavsiya etiladigan qoidalar

Require a pull request before merging

main-ga to'g'ridan-to'g'ri merge qilish taqiqlanadi. Har qanday o'zgarish avval PR orqali o'tishi shart.

Require approvals

PR merge qilinishi uchun kamida N muhandis tasdiqlashi kerak. Kichik jamoalar uchun 1, kattaroq jamoalar uchun 2 tavsiya etiladi. Ko'p tasdiqlash talab qilish xavfsizlikni oshiradi, lekin jarayonni sekinlashtiradi.

Require review from Code Owners

Tasdiqlash beruvchilardan kamida bittasi CODEOWNERS faylida ko'rsatilgan senior muhandis bo'lishi shart. Bu oddiy muhandislar emas, faqat senior muhandis tasdiqlagandagina merge mumkin bo'lishini ta'minlaydi.

Require status checks to pass before merging

GitHub Actions orqali testlar yoki build tekshirishlar o'rnatilgan bo'lsa, ularning hammasi muvaffaqiyatli o'tmaguncha merge taqiqlanadi. Hali testlar yo'q bo'lsa ham, keyinchalik qo'shilganda bu qoida tayyor bo'lishi uchun belgilab qo'yish mumkin.

Require branches to be up to date before merging

Branch main-dan orqada (behind) bo'lsa, avval main-ning so'nggi o'zgarishlarini olish shart. Bu merge paytidagi konfliktlarni oldindan kamaytiradi.

Require conversation resolution before merging

PR-dagi barcha izohlar (Resolve conversation bosib) yopilmagunicha merge taqiqlanadi. Bu muhokadalar e'tiborga olinmasdan PR merge qilinib ketishini oldini oladi.

Restrict who can push to matching branches

Faqat belgilangan foydalanuvchilar yoki guruhlar main-ga push qila oladi.

Muhim: Allow force pushes va Allow deletions — bu ikkisini main uchun hech qachon yoqmang. Force push main tarixini qayta yozadi va butun reponi buzishi mumkin.

2. CODEOWNERS fayli

CODEOWNERS fayli — PR-ni kim tasdiqlashi kerakligini GitHub-ga bildiruvchi fayl. Bu faylda ko'rsatilgan foydalanuvchilar "kod egalari" (code owners) hisoblanadi.

Fayl joylashuvi

repo/
└── .github/
    └── CODEOWNERS

GitHub-da fayl yaratish: repo asosiy sahifasida Add file → Create new file, fayl nomi qatoriga .github/CODEOWNERS kiriting — GitHub papkani avtomatik yaratadi.

CODEOWNERS fayl tarkibi

# Repo-dagi barcha fayllar uchun standart egalar
* @username1 @username2

# Faqat ma'lum papka uchun egalar
/docs/ @docs-team

# Faqat ma'lum fayl turi uchun egalar
*.swift @ios-team

Eng oddiy holat — barcha fayllar uchun bitta yoki bir nechta code owner:

* @senior-engineer-username

Fayl to'g'ri sozlangandan so'ng, GitHub-da istalgan fayl sahifasida kichik qalqon belgisi (🛡) paydo bo'ladi — u shu faylning code owner(lar)ini ko'rsatadi.

3. PR shabloni (Pull Request Template)

PR shabloni — yangi PR yaratilganda tavsif maydoniga avtomatik yuklaninadigan Markdown fayl. Barcha muhandislar bir xil formatda kerakli ma'lumotlarni kiritishini ta'minlaydi.

Fayl joylashuvi va nomi

repo/
└── .github/
    └── pull_request_template.md

Nom aniq shu bo'lishi shart — boshqacha nomlangan fayl ishlamaydi.

PR shablon namunasi

## Tavsif

### Ticket

[ABC-123](https://jira.example.com/browse/ABC-123)

### Nima o'zgardi?

<!-- Bir jumla bilan asosiy o'zgarishni tushuntiring -->

### Nima uchun shu yondashuv tanlandi?

<!-- Chalkash ko'rinishi mumkin bo'lgan kod bo'lsa, sababini tushuntiring -->

### Nimalarda shubha bor?

<!-- Qayta ko'rib chiqilishi kerak bo'lgan joylarni ko'rsating -->

---

## O'zgarish turi

- [ ] Yangi funksionallik
- [ ] Xatolik tuzatish
- [ ] Refactoring
- [ ] Hujjatlashtirish

---

## Tekshiruv ro'yxati

- [ ] Testdan o'tgan (ishlaydi, compilatsiya qiladi)
- [ ] Kod uslubiga mos
- [ ] Hujjatlar yangilangan (agar zarur bo'lsa)
- [ ] Yangi testlar qo'shilgan (agar zarur bo'lsa)
- [ ] Breaking change yo'q

---

## Skrinshotlar (UI o'zgarishlari uchun)

<!-- Oldingi va yangi ko'rinish skrinshoti -->

---

## Qo'shimcha

<!-- Boshqa muhim ma'lumotlar -->

Ticket havolasini Markdown-da qanday qilish

[ABC-123](https://jira.example.com/browse/ABC-123)

Bu havola sifatida ko'rinadi — ko'rib chiquvchi bir marta bosib ticket-ga o'tishi mumkin.

Fayllarni repoga qo'shish

Ikkala fayl ham GitHub-da to'g'ridan-to'g'ri yaratilishi yoki local-dan commit qilinishi mumkin:

.github/
├── CODEOWNERS
└── pull_request_template.md

Fayllar main-ga commit qilingandan so'ng darhol ishlaydi — keyingi PR yaratilganda shablon avtomatik yuklanadi va kod egalilik qoidalari kuchga kiradi.

Himoyalangan branchda merge qilish

Branch rules o'rnatilgandan so'ng, hatto repo egasi ham main-ga to'g'ridan-to'g'ri merge qila olmaydi — agar bir nechta tasdiqlash talab qilinsa, o'zining PR-ini o'zi approve qilish texnik jihatdan bloklangan.

Repo egasi Bypass opsiyasidan foydalanishi mumkin — lekin bu faqat favqulodda holatlarda qo'llanadi. Junior muhandislar bypass qila olmaydi.

Xulosa

Bu darsda o'rganildi:

• Branch Protection Rules — main-ga to'g'ridan-to'g'ri merge va force push-ni taqiqlash, PR va tasdiqlashni majburiy qilish
• Tavsiya etiladigan qoidalar: Require PR, Require approvals, Require Code Owner review, Require status checks, Require up to date branch, Require conversation resolution
• Allow force pushes va Allow deletions — main uchun hech qachon yoqilmaydi
• CODEOWNERS — .github/CODEOWNERS faylida * @username formatida code owner belgilanadi
• PR shabloni — .github/pull_request_template.md faylida Markdown formatida yaratiladi, yangi PR-larda avtomatik yuklanadi
• Yaxshi shablon: tavsif, ticket havolasi, o'zgarish turi, tekshiruv ro'yxati, skrinshotlar

Keyingi darsda git flow va professional muhitda git jarayonlari ko'rib chiqiladi.