Published on: Wednesday, October 28, 2026

Git Flow-dan qanday foydalanish kerak va Git Professional bo'lish

Authors

Name
ShoxruxC
@iOSdasturchi

Git Flow nima va nima uchun kerak

Hozirgacha biz commit, clone, push, pull, branch, merge, rebase, cherry pick, PR, tag, release va versiyalashni o'rgandik. Endi esa muhim savol: qachon commit qilish kerak? Qachon merge qilish kerak? Jamoada production muhitida bu qanday ishlaydi?

Har bir kompaniya o'zining kichik farqlari bilan ishlashi mumkin, ammo umuman olganda ko'pchilik kompaniyalar Git Flow deb ataladigan narsaga amal qiladi. Bu — qachon branch yaratish va qachon merge qilish kerakligi haqidagi eng yaxshi amaliyot (best practice) va pattern.

Git Flow — jamoada git tarixini tartibli va samarali boshqarish uchun qabul qilingan standart yondashuv.

Git Flow-ning asosiy tuzilmasi

Ikkita asosiy branch

Git Flow-da har doim ikkita asosiy branch mavjud:

main ─────────────────────────────────────►  (faqat release-lar)
  │
develop ──────────────────────────────────►  (barcha joriy ish)

Branch	Maqsad
`main`	Faqat release commit-lari — kod foydalanuvchilarga yetganda yangilanadi
`develop`	Barcha joriy ishlar — asosiy ish shu yerda bajariladi

Feature branch-lari

Yangi funksiya qurish uchun, develop-dan branch yaratiladi:

develop ──┬─────────────────────────────►
           │
           └── feature/some-feature
                  (commit-lar...)
                  merged → develop

Funksiya tayyor bo'lgach, develop-ga merge qilinadi va branch o'chiriladi. Keyingi funksiya uchun — yana yangi branch, yana develop-ga merge. Bu jarayon hafta davomida davom etadi.

Release branch-i

Har ikki haftada yoki oyda bir marta, develop-dagi to'plangan funksiyalar foydalanuvchilarga chiqariladi:

develop ──┬──────────────────────────────►
           │
           └── release/1.0.0
                  (final tweaks, bug fix-lar...)
                  merged → main
                  merged → develop

Release branch yaratilgandan keyin:

develop-da ish davom etishi mumkin (bu o'zgarishlar keyingi releasega kiradi)
Release branch-da faqat final tuzatishlar amalga oshiriladi
Tayyor bo'lgach — main-ga merge (PR orqali)
main-dan ham develop-ga merge (yoki hotfix-lar bilan)

Hotfix branch-i

Production-da kritik xatolik topilganda:

main ──┬────────────────────────────────►
        │
        └── hotfix/fix-crash
               (tuzatish...)
               merged → main   (yangi patch release)
               merged → develop (develop-ni yangilash)

Hotfix develop-dan emas, main-dan branch qilinadi — chunki develop-da hali chiqarilmagan o'zgarishlar bor, biz esa faqat production-dagi muammoni hal qilmoqchimiz.

Git Flow qadama-qadam

1. Dastlabki sozlash

main      → dastlabki commit
develop   → main-dan yaratiladi

2. Feature qurish

feature/add-login → develop-dan branch
commit-lar...
PR → develop-ga merge
branch o'chiriladi

3. Navbatdagi feature

feature/home-screen → develop-dan branch
commit-lar...
PR → develop-ga merge
branch o'chiriladi

4. Release tayyorlash

release/1.0.0 → develop-dan branch
version number yangilanadi
final bug fix-lar...
PR → main-ga merge (squash & merge)
Tag qo'shiladi: v1.0.0
GitHub Release yaratiladi
develop-ga ham merge (yoki main → develop)
branch o'chiriladi

5. Hotfix (agar kerak bo'lsa)

hotfix/fix-analytics → main-dan branch
tuzatish commit-i
version: 1.0.1
PR → main-ga merge
Tag: v1.0.1
PR → develop-ga merge (conflict bo'lishi mumkin)
branch o'chiriladi

Amaliy misol: to'liq Git Flow

Boshlash: develop branch yaratish

main → develop branch yaratish → remote-ga push

Endi barcha ish develop-da amalga oshiriladi.

Feature-lar qurish

Feature 1: Login funksiyasi

// LoginView.swift-ga o'zgarishlar

feature/add-login-view branchda:
commit: "Add login view"
commit: "Add login button action"
PR → develop-ga merge (squash & merge tavsiya etiladi)

Feature 2: Profile sahifasi

// ProfileView.swift-ga o'zgarishlar

feature/add-profile-view branchda:
commit-lar...
PR → develop-ga merge

Release tayyorlash

Develop-da yetarlicha funksiyalar to'plangach:

develop → release/1.0.0 branch yaratish

Release branchda:

Version number va build number yangilanadi
Final sinov o'tkaziladi
Kichik bug-lar tuzatiladi

commit: "Release 1.0.0 build 1"

GitHub-da PR yaratish: release/1.0.0 → main

PR-ni ko'rib chiqish (review)
Squash and merge yoki Merge commit tanlash
Merge qilingach branch o'chiriladi

Tag va Release yaratish:

main branchida: Tag → v1.0.0
GitHub → Releases → Draft new release
Tag: v1.0.0
Auto-generate release notes → Publish

develop-ni ham yangilash:

main → develop-ga merge (yoki develop → main-dagi o'zgarishlarni pull)

Hotfix: production xatoligini tuzatish

Aytaylik, v1.0.0 chiqarilgandan so'ng, analytics xatoligi topildi:

main → hotfix/fix-analytics branch

// ProfileView.swift-da analytics tuzatiladi

commit: "Patch: Fix analytics in profile view"
version: 1.0.1, build: 2
commit: "Release 1.0.1 build 2"

PR 1: hotfix/fix-analytics → main

Ko'rib chiqiladi, merge qilinadi
Tag: v1.0.1
GitHub Release: v1.0.1

PR 2: hotfix/fix-analytics → develop

Bu yerda conflict bo'lishi mumkin (develop-da boshqa o'zgarishlar ham bor)
Conflict-ni hal qilamiz — hotfix-dan kelgan kodni saqlaymiz

branch o'chiriladi

Main branch tarixining ko'rinishi

Git Flow-dan foydalanganda, main branchi juda toza ko'rinadi:

main:
  initial commit
  ↓
  merge: release/1.0.0   ← v1.0.0
  ↓
  merge: hotfix/1.0.1    ← v1.0.1
  ↓
  merge: release/1.1.0   ← v1.1.0

Har yuz-yuz commit o'rniga, faqat release-lar ko'rinadi. Bu — "sacred timeline" (muqaddas tarix). develop branchida esa barcha kundalik ishlar, commit-lar va feature merge-lari saqlanadi.

GitKraken-da ko'rinish

GitKraken-da Git Flow-ni rangli grafik shaklida ko'rish mumkin:

main — bir rang
develop — boshqa rang
feature/* — uchinchi rang
hotfix/* — qizil rang

Murakkab loyihalarda, ko'p dasturchi bilan ishlayotganda, bu vizual ko'rinish juda muhim — kim qaysi branchda ishlayotgani, branchlar qayerda ajralib, qaerda birlashgani bir qarashda ko'rinadi.

Xulosa: Git Flow qoidalari

Branch turi	Manbadan	Maqsad branchiga
`feature/*`	`develop`	`develop`
`release/*`	`develop`	`main` + `develop`
`hotfix/*`	`main`	`main` + `develop`

Asosiy qoidalar:

main — faqat release commit-lari, doim toza va barqaror
develop — barcha joriy ish, doim eng so'nggi holat
Feature-lar — develop-dan, develop-ga qaytadi
Release-lar — develop-dan, main-ga (va develop-ga) qaytadi
Hotfix-lar — main-dan, main-ga va develop-ga qaytadi

Qachon Git Flow-ni ishlatish kerak

Holat	Tavsiya
Yolg'iz, shaxsiy loyiha	Git Flow majburiy emas — minimum: `develop` + `main`
Kichik jamoa (2-5 kishi)	Git Flow tavsiya etiladi
Katta jamoa, production app	Git Flow zarur

Agar o'zingizning shaxsiy loyihangizda bo'lsangiz, hech bo'lmaganda develop branch yarating va funksiyalarni shu yerda qurib, faqat releaseda main-ga merge qiling — bu ham katta qadam.

Git Flow-ni birinchi marta qilish murakkab tuyuladi. Ammo bir necha marta amalda qilib ko'rganingizdan so'ng, bu sizning oddiy ish jarayoningizga aylanadi va butun jamoaning samaradorligini keskin oshiradi.