4.4-bob: Git workflow'lar (Gitflow, trunk-based)

4-QISM — Git va hamkorlik · 4-mavzu

1. Kirish va motivatsiya

Git buyruqlarini (4.1–4.3) bildik — branch, merge, PR. Lekin jamoa ularni qaysi tartibda, qanday qoidalar bilan ishlatadi? Bu — workflow (ish jarayoni) masalasi. Workflow'siz jamoa — har kim o'zicha ishlaydi, main buziladi, conflict ko'payadi, chalkashlik.

Git workflow — branch'lar va relizlarni boshqarishning kelishilgan qoidalari: qaysi branch nima uchun, qachon merge, qanday reliz. To'g'ri workflow — barqaror main, toza tarix, oson hamkorlik beradi.

O'xshatish: workflow — yo'l harakati qoidalari. Mashina (Git) va haydash (buyruqlar) bilsangiz ham, qoidasiz (svetofor, yo'lak) — tartibsizlik va halokat. Workflow — jamoa "qaysi yo'lakda yurish, qachon to'xtash" ni kelishishi. Har jamoa o'z qoidasini tanlaydi, lekin kelishilgan bo'lishi shart.

Nega muhim?

Jamoa tartibi — har kim bir xil qoida bilan ishlaydi.
Barqaror main — production doim ishlaydigan holatda.
To'g'ri tanlov — loyiha turiga mos workflow (kichik startup ≠ katta korxona).
CI/CD 10.5-bob, reliz boshqaruvi — workflow'ga bog'liq.

2. Nazariya — chuqur tushuntirish

2.1. Workflow nima va nega kerak?

Workflow — jamoa kelishgan branch/merge/reliz qoidalari. U javob beradi:

Qaysi branch'lar bor va nima uchun?
Yangi feature qayerdan branch oladi, qayerga merge bo'ladi?
Reliz qanday chiqariladi?
mainga kim, qachon, qanday qo'shadi?

Uch asosiy workflow bor: GitHub Flow (sodda), Gitflow (murakkab, rejali), Trunk-based (uzluksiz).

2.2. GitHub Flow — eng sodda, eng keng tarqalgan

GitHub Flow — eng oddiy va zamonaviy (kichik/o'rta jamoa, web ilovalar):

text

  main (doim deploy'ga tayyor, barqaror)
   │
   ├── feature-x   PR  review  merge  main  deploy
   ├── fix-y       PR  review  merge  main  deploy

Qoidalar:

main — doim deploy'ga tayyor (barqaror).
Har ish uchun maindan branch 4.2-bob.
Tayyor bo'lsa — Pull Request 4.3-bob review merge.
Merge bo'lgach — darrov deploy.

GitHub Flow — kichik jamoa, tez yetkazib berish (continuous deployment), web loyihalar uchun ideal. Sodda, tushunarli. Ko'p startup va loyiha shuni ishlatadi.

2.3. Gitflow — rejali relizlar uchun

Gitflow — murakkabroq, rejali reliz sikli bor loyihalar uchun (Atlassian). Ikki doimiy branch:

text

  main     — faqat RELIZLAR (har commit — reliz, teglar bilan)
  develop  — integratsiya branch (kelajak reliz to'planadi)
   │
   ├── feature/*  develop ga merge (yangi imkoniyatlar)
   ├── release/*  main + develop (reliz tayyorlash)
   └── hotfix/*   main + develop (production shoshilinch tuzatish)

Branch turlari:

main — production relizlar (har biri teg bilan — versiya).
develop — keyingi reliz to'planadigan integratsiya branch.
feature/* — yangi imkoniyatlar (developdan, developga).
release/* — relizni tayyorlash (test, tuzatish).
hotfix/* — production'dagi kritik xato (maindan, main+developga).

Gitflow — katta, rejali reliz (masalan v1.0, v1.1, v2.0) bor loyihalar; bir necha versiya parallel qo'llab-quvvatlanadigan mahsulotlar uchun. Lekin web ilovalar uchun ko'pincha juda murakkab.

2.4. Trunk-based development — uzluksiz yetkazib berish

Trunk-based — hamma bitta asosiy branch'da (main/trunk) ishlaydi; branch'lar juda qisqa umrli (Atlassian):

text

  main (trunk)  ── juda qisqa umrli branch'lar (bir necha soat/kun)
                ── tez-tez merge (kuniga bir necha marta)
                ── feature flags bilan tugallanmagan kod yashiriladi

Qoidalar:

Hamma mainga tez-tez (kuniga) merge qiladi.
Branch'lar juda qisqa umrli (uzoq yashash — conflict).
Tugallanmagan feature feature flag (yoqib/o'chirib qo'yiladigan) bilan yashiriladi.
Kuchli avtomatik test 10.5-bob — main doim ishlaydigan.

Trunk-based — tajribali jamoalar, uzluksiz yetkazib berish (CI/CD — 10.5), kunlik deploy uchun. Google, Facebook kabi kompaniyalar ishlatadi. Kuchli test madaniyatini talab qiladi.

2.5. Qaysi workflow qachon?

Workflow	Murakkablik	Qachon
GitHub Flow	sodda	kichik/o'rta jamoa, web, tez deploy (default tanlov)
Gitflow	murakkab	rejali reliz, versiyalangan mahsulot, bir necha versiya
Trunk-based	o'rta (lekin intizom)	katta jamoa, CI/CD, kunlik deploy, feature flags

Maslahat: ko'p loyiha uchun GitHub Flow (sodda) yetadi. Gitflow — faqat haqiqatan rejali reliz kerak bo'lsa. Trunk-based — kuchli test/CI bo'lsa. Eng yaxshi workflow — jamoa amal qiladigani.

2.6. Branch nomlash konvensiyalari

Workflow'dan qat'i nazar, branch nomlari mazmunli va izchil bo'lsin:

text

  feature/login-form       feat/user-profile
  fix/auth-bug             bugfix/cart-total
  hotfix/payment-crash     chore/update-deps
  docs/readme              refactor/api-layer

Format: tur/qisqa-tavsif (tire bilan). Tur: feature/fix/hotfix/docs/chore/refactor.

Maslahat: ko'p jamoa branch nomiga issue/task raqamini ham qo'shadi (feature/142-login-form) — branch va vazifa o'rtasida bog'lanish bo'ladi. Ortiqcha uzun nom qilmang.

2.7. Monorepo va polyrepo (qisqacha)

Workflow — branch'larni boshqarish bo'lsa, repozitoriya tuzilmasi — kodni nechta repoga bo'lish masalasi. Ikki yondashuv:

text

  POLYREPO:  har loyiha/servis — alohida repo
             frontend-repo  backend-repo  shared-lib-repo

  MONOREPO:  hamma kod — bitta katta repo
             /apps/frontend  /apps/backend  /packages/shared-lib

Polyrepo (ko'p repo) — har komponent o'z repo'sida, mustaqil. Sodda, lekin repolar orasidagi umumiy kod va versiyani moslash qiyinlashadi.
Monorepo (bitta repo) — hamma kod bir joyda; umumiy kodni ulashish, bir commit'da bir nechta komponentni o'zgartirish oson. Lekin repo kattalashadi, maxsus asboblar (Nx, Turborepo) kerak bo'lishi mumkin.

Qaysi biri? Kichik/o'rta loyihalar uchun ko'pincha polyrepo (yoki bitta oddiy repo) yetadi. Monorepo — komponentlar bir-biriga zich bog'liq, umumiy kod ko'p bo'lganda (masalan Google ichki kodi). Workflow (GitHub Flow, Gitflow, trunk-based) ikkala tuzilmada ham qo'llanadi — ular bir-biriga zid emas.

2.8. Protected branches va review qoidalari

Jamoa odatda mainni himoyalaydi (GitHub sozlamasi):

mainga to'g'ridan-to'g'ri push taqiqlanadi (faqat PR).
PR uchun kamida 1 reviewer ma'qullashi shart.
CI testlar o'tishi shart 10.5-bob.
Branch yangilangan bo'lishi (main bilan).

Bu — mainning barqarorligini kafolatlaydi 2.2-bob.

3. Workflow'lar — tez ma'lumotnoma

text

GITHUB FLOW:   main (barqaror) + qisqa feature branch'lar  PR  merge  deploy
                kichik/o'rta jamoa, web (DEFAULT)

GITFLOW:       main (reliz) + develop + feature/release/hotfix
                rejali reliz, versiyalangan mahsulot

TRUNK-BASED:   main + juda qisqa branch'lar + feature flags + kuchli test
                katta jamoa, CI/CD, kunlik deploy

BRANCH NOM:    tur/tavsif (feature/login, fix/auth-bug)
HIMOYA:        main — faqat PR, review + CI shart

4. Batafsil amaliy namunalar

Misol 1 — GitHub Flow sikli (2.2)

bash

git switch main && git pull              # barqaror main'dan boshla
git switch -c feature/search             # feature branch (4.2, 2.6)

# (kod yoz, commit — 4.1)
git push -u origin feature/search        # push (4.3)
# GitHub'da PR och  review  CI  merge  deploy
git switch main && git pull && git branch -d feature/search

Misol 2 — Gitflow feature sikli (2.3)

bash

# Gitflow: feature develop'dan oladi, develop'ga qaytaradi
git switch develop && git pull
git switch -c feature/user-profile       # develop'dan

# (ishla, commit)
git push -u origin feature/user-profile
# PR: feature/user-profile  develop (main'ga emas!)
# merge bo'lgach develop'da to'planadi (keyingi reliz uchun)

Misol 3 — Hotfix (Gitflow — 2.3)

bash

# Production'da kritik xato — main'dan to'g'ridan hotfix
git switch main && git pull
git switch -c hotfix/payment-crash       # main'dan (develop'dan emas!)

# (xatoni tuzat, commit)
git push -u origin hotfix/payment-crash
# PR: hotfix  main (darrov deploy) VA hotfix  develop (kelajakda ham bo'lsin)

Misol 4 — Trunk-based (feature flag — 2.4)

bash

git switch main && git pull
git switch -c feat/new-checkout          # juda qisqa umrli

# Tugallanmagan feature'ni FEATURE FLAG bilan yashir (kodda):
# if (FEATURES.newCheckout) { yangiCheckout() } else { eskiCheckout() }
git add . && git commit -m "feat: yangi checkout (flag ortida)"
git push -u origin feat/new-checkout
# Tez PR  merge (bir necha soatda) — main'ga, lekin flag o'chiq
# Tayyor bo'lganda flag yoqiladi (kod allaqachon main'da)

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

1) Workflow'siz ishlash (jamoada)

text

 har kim o'zicha, qoidasiz  main buziladi, chalkashlik
 jamoa bitta workflow'ni kelishadi va amal qiladi (2.1)

2) Kichik loyihaga Gitflow (ortiqcha murakkablik)

text

 oddiy web ilova uchun develop/release/hotfix — keraksiz murakkablik
 GitHub Flow (sodda) — ko'p loyiha uchun yetarli (2.5)

3) Uzoq yashagan branch'lar

text

 branch 2 hafta yashaydi  main'dan uzoqlashadi  ko'p conflict (4.2)
 kichik, qisqa umrli branch'lar  tez-tez merge (2.4)

4) Mazmunsiz branch nomlari

bash

#  test, test2, ali-branch, asd
#  feature/login, fix/auth-bug (2.6)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Jamoa har xil workflow ishlatadi

Sababi: kelishilmagan 2.1-bob. Yechimi: jamoa bitta workflow'ni hujjatlab kelishsin (CONTRIBUTING.md).

Xato 2 — main buzilgan (production ishlamaydi)

Sababi: sinalmagan kod mainga merge 2.2-bob. Yechimi: protected branch + PR review + CI 2.8-bob; mainni doim barqaror tuting.

Xato 3 — Ko'p conflict (har merge'da)

Sababi: uzoq yashagan, katta branch'lar (3-holat). Yechimi: kichik, qisqa branch'lar; tez-tez maindan yangilash 4.2-bob.

Xato 4 — Gitflow chalkashligi (qaysi branch qayerga?)

Sababi: murakkab branch tuzilmasi 2.3-bob. Yechimi: loyiha sodda bo'lsa GitHub Flow'ga o'ting; Gitflow'ni faqat haqiqatan kerak bo'lsa.

Xato 5 — Hotfix develop'ga qaytarilmadi

Sababi: hotfix faqat mainga, developga emas keyingi relizda xato qaytadi 2.3-bob. Yechimi: hotfix'ni ikkalasiga ham merge.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

Branch/merge 4.2-bob: workflow — branch strategiyasi.
PR 4.3-bob: review qoidalari workflow'ning bir qismi.
CI/CD 10.5-bob: trunk-based — kuchli avtomatik test talab qiladi; PR'da CI.
Conventional commits 4.5-bob: commit standarti workflow'ni to'ldiradi.
Deploy (10): GitHub Flow — merge deploy.
Code review 15.2-bob: PR review — workflow markazida.
Feature flags (trunk-based): tugallanmagan kodni boshqarish.
Monorepo/polyrepo 2.7-bob: repozitoriya tuzilmasi — workflow ikkala holatda ham qo'llanadi.

8. Eng yaxshi amaliyotlar (best practices)

Bitta workflow'ni kelishing va amal qiling — eng yaxshisi — jamoa rioya qiladigani 2.5-bob.
Ko'p loyiha uchun GitHub Flow (sodda) — keragidan murakkab qilmang 2.2-bob.
mainni doim barqaror tuting — protected branch + PR + CI 2.8-bob.
Kichik, qisqa umrli branch'lar — conflict kamayadi (2.4, 4.2).
Mazmunli, izchil branch nomlari (feature/..., fix/... — 2.6).
Gitflow — faqat rejali reliz kerak bo'lsa; trunk-based — kuchli test bo'lsa.
Workflow'ni hujjatlang (CONTRIBUTING.md) — yangi a'zolar uchun.
Hotfix'ni barcha kerakli branch'larga merge qiling (Gitflow — 2.3).

9. Amaliy loyiha: "Jamoa Workflow Simulyatsiyasi"

Git workflow'larni amalda his qilish (yolg'iz yoki do'stingiz bilan).

Maqsad

GitHub Flow va Gitflow'ni amalda qo'llab, branch strategiyasi, reliz va hotfix sikllarini tushunish.

Talablar (requirements)

GitHub Flow loyihasi: main barqaror; bir necha feature branch (feature/...) PR merge sikli (Misol 1, 2.2).
Branch nomlash: barcha branch'lar tur/tavsif formatida 2.6-bob.
Protected main: GitHub'da mainni himoyalang (to'g'ridan push taqiq, PR shart — 2.8).
Gitflow simulyatsiyasi: develop branch yarating; feature develop; release main; bir reliz teg bilan (v1.0.0 — Misol 2, 2.3).
Hotfix sikli: maindan hotfix main + develop (Misol 3, 2.3).
Trunk-based g'oyasi: feature flag bilan tugallanmagan kodni yashirib, tez merge (Misol 4, 2.4).
Solishtirish: uchala workflow'ning afzallik/kamchiligini loyihangiz uchun yozing 2.5-bob.
CONTRIBUTING.md: tanlangan workflow qoidalarini hujjatlang.

Maslahatlar (hint)

GitHub Flow'dan boshlang (sodda — 2.2).
Branch nomlari izchil (feature/, fix/, hotfix/ — 2.6).
Reliz teg: git tag v1.0.0 && git push --tags.
Feature flag — oddiy const FEATURES = { x: false } (Misol 4).
Protected branch — GitHub repo Settings Branches.
Hotfix — main va develop ikkalasiga (5-xato).

"Tayyor" mezonlari (acceptance criteria)

GitHub Flow sikli (feature PR merge) ishlaydi.
Barcha branch nomlari tur/tavsif formatida.
main himoyalangan (PR shart).
Gitflow: develop + feature + release + teg ko'rsatilgan.
Hotfix main va develop'ga merge qilingan.
Feature flag bilan trunk-based g'oyasi ko'rsatilgan.
Workflow'lar solishtirilgan; CONTRIBUTING.md yozilgan.

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

10. Xulosa va keyingi bobga ko'prik

Bu bobda jamoa Git'ni qanday tartibda ishlatishini — workflow'larni o'rgandik:

Workflow — branch/merge/reliz qoidalari (jamoa kelishuvi).
GitHub Flow — sodda: main barqaror + qisqa feature branch PR merge deploy (default, web).
Gitflow — murakkab: main+develop+feature/release/hotfix (rejali reliz, versiyalangan).
Trunk-based — main + juda qisqa branch + feature flags + kuchli test (CI/CD, kunlik deploy).
Branch nomlash (tur/tavsif), protected main (PR+review+CI).
Best: jamoa rioya qiladigan workflow; main barqaror; kichik branch'lar.

Keyingi bob — 4.5-bob: Conventional commits va .gitignore. Workflow'ni bildik; endi ikki muhim detalni to'liq ochamiz: conventional commits (commit xabarlarining standarti — avtomatlashtirish, toza tarix) va .gitignore (qaysi fayllarni Git'dan istisno qilish). Bu — 4-QISMning yakuni.

Foydalanilgan rasmiy/ishonchli manbalar

Atlassian Git Tutorial — Gitflow, comparing workflows
atlassian.com / trunkbaseddevelopment.com — trunk-based development
docs.github.com — GitHub Flow, protected branches

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!