Gitflow — main, develop, feature, release, hotfix branch lari

~20 daq · Git · Professional Git Workflow

Muammodan boshlaylik

Siz texnik jihatdan Git ni bilasiz: branch, merge, rebase. Lekin jamoada savollar tug'iladi:

  • Feature branch qayerdan yaratiladi — main danmi?
  • Test qilinayotgan, lekin hali chiqarilmagan kod qayerda turadi?
  • Reliz tayyorlanayotganda yangi funksiyalar qo'shilsa-chi?
  • Production dagi shoshilinch xato qanday tuzatiladi, agar main da allaqachon yarim tayyor yangi kod bo'lsa?

Har kim o'zicha javob bersa — tartibsizlik. Jamoaga kelishilgan qoidalar kerak — workflow (ish oqimi). Eng mashhur va eng to'liq klassik workflow — Gitflow.

Gitflow — umumiy ko'rinish

2010 yilda Vincent Driessen taklif qilgan model. Ikki doimiy va uch turdagi vaqtinchalik branch:

 main      ●─────────────────────●───────────●──────────────●     (faqat relizlar)
           │                    ↗ v1.0       ↑ v1.0.1       ↑ v1.1
 hotfix    │                   │      ●──────┘│             │
           │                   │     ↗        ↓             │
 release   │            ●──●───┤    │         │      ●──●───┤
           │           ↗       ↓    │         ↓     ↗       ↓
 develop   ●──●──●──●──●───────●────●─────────●──●──●───────●──    (integratsiya)
               ↘     ↗              ↘     ↗
 feature        ●──●                 ●──●

Doimiy branch lar

Branch Vazifasi
main Faqat production dagi kod. Har bir commit — reliz, teg bilan (v1.0.0)
develop Keyingi reliz uchun integratsiya: barcha tayyor funksiyalar shu yerda yig'iladi

Vaqtinchalik branch lar

Branch Qayerdan Qayerga Nomi
feature develop develop feature/savat
release develop main va develop release/1.1.0
hotfix main main va develop hotfix/1.0.1

Feature branch

Yangi funksiya — doim develop dan:

git switch develop
git pull
git switch -c feature/savat
# ... ish, commitlar ...
git push -u origin feature/savat
# PR: feature/savat → develop

Merge qilingandan keyin branch o'chiriladi. main ga feature to'g'ridan-to'g'ri hech qachon tushmaydi.

Release branch

develop da keyingi reliz uchun yetarli funksiya to'plandi:

git switch develop
git switch -c release/1.1.0

Release branch da:

  • ✅ Xatolarni tuzatish (QA testlari natijasida)
  • ✅ Versiya raqamini yangilash (package.json), CHANGELOG
  • ❌ Yangi funksiyalar — yo'q — ular develop ga ketadi, keyingi relizga

Bu paytda boshqa dasturchilar develop da keyingi relizni bemalol davom ettiradi — release "muzlatilgan".

Tayyor bo'lganda:

# 1. main ga
git switch main
git merge --no-ff release/1.1.0
git tag -a v1.1.0 -m "Versiya 1.1.0"
git push origin main --tags

# 2. develop ga — release dagi tuzatishlar yo'qolmasin
git switch develop
git merge --no-ff release/1.1.0
git push

# 3. O'chirish
git branch -d release/1.1.0

Hotfix branch

Production da (main, v1.1.0) jiddiy xato. develop da esa allaqachon yarim tayyor v1.2 kodi — undan reliz qilib bo'lmaydi.

git switch main
git switch -c hotfix/1.1.1
# ... tuzatish, versiyani 1.1.1 ga ...
git commit -am "To'lov: summa yaxlitlash xatosi tuzatildi"

git switch main
git merge --no-ff hotfix/1.1.1
git tag -a v1.1.1 -m "Versiya 1.1.1"

git switch develop
git merge --no-ff hotfix/1.1.1       # tuzatish keyingi relizda ham bo'lsin!

git branch -d hotfix/1.1.1
git push origin main develop --tags

[!WARNING] Hotfix va release ni ikkala branch ga (main va develop) qo'shishni unutmang. develop ga qo'shilmasa — keyingi relizda xato qaytib keladi. Bu Gitflow dagi eng ko'p uchraydigan xato.

git-flow vositasi

Bu qadamlarni avtomatlashtiruvchi kengaytma:

git flow init                         # branch nomlarini sozlash
git flow feature start savat
git flow feature finish savat
git flow release start 1.1.0
git flow release finish 1.1.0         # main ga, develop ga, teg — hammasi
git flow hotfix start 1.1.1
git flow hotfix finish 1.1.1

Qulay, lekin jamoalar ko'pincha PR orqali ishlaydi va qo'lda (yoki GitHub da) merge qiladi.

Gitflow qachon mos keladi

✅ Mos:

  • Rejalashtirilgan relizlar — mobil ilovalar (App Store ko'rib chiqishi), quti dasturlar, kutubxonalar
  • Bir vaqtda bir nechta versiya qo'llab-quvvatlanadi (v1.x va v2.x)
  • Reliz oldidan uzoq QA bosqichi
  • Katta jamoa, qat'iy jarayonlar

❌ Mos emas:

  • Veb-ilovalar uzluksiz deploy bilan — kuniga bir necha marta production ga
  • Kichik jamoa
  • Har bir merge avtomatik deploy qilinadigan CI/CD

[!INFO] Gitflow muallifining o'zi 2020 yilda maqolasiga eslatma qo'shdi: "Agar jamoangiz uzluksiz yetkazib berish (continuous delivery) bilan ishlasa, GitHub Flow kabi soddaroq workflow ni tavsiya qilaman". Bugun ko'pchilik veb-loyihalar soddaroq modellarni tanlaydi — keyingi dars.

Nima uchun shunday?

Nima uchun Gitflow da ikkita doimiy branch — main va develop — bitta yetmaydimi?

Chunki ular ikki turli savolga javob beradi. main — "hozir production da nima ishlayapti?" — doim aniq, barqaror, teglangan. develop — "keyingi reliz qanday bo'ladi?" — doim o'zgaruvchan, integratsiya joyi. Bitta branch bo'lsa, ular to'qnashadi: shoshilinch tuzatish uchun production versiyasini topish qiyin, chunki branch da allaqachon yarim sinovdan o'tgan yangi kod bor. Gitflow ularni ajratadi — va bu tartib rejalashtirilgan relizlar uchun juda yaxshi ishlaydi. Lekin har bir ajratish narx bilan keladi: ko'proq merge, ko'proq branch, ko'proq qoida. Uzluksiz deploy dunyosida bu narx foydadan oshib ketadi.

Xulosa

Eslab qoling:

  • Workflow — jamoaning branch lar bo'yicha kelishilgan qoidalari
  • Gitflow: main (production, teglar) + develop (integratsiya)
  • feature — develop dan → develop ga
  • release — develop dan → main + develop ga; faqat tuzatishlar, yangi funksiya yo'q
  • hotfix — main dan → main + develop ga
  • --no-ff merge, har bir reliz — main da teg
  • Mos: rejalashtirilgan relizlar, bir nechta versiya, mobil, kutubxonalar
  • Uzluksiz deploy li veb-loyihalar uchun — soddaroq workflow

Keyingi dars

33-dars: GitHub Flow — soddaroq workflow, qachon mos keladi