Git da tarmoqlash strategiyalari: Git Flow, GitHub Flow, trunk-based

Qisqa javob

Tarmoqlash strategiyasi — jamoaning qanday branch lar mavjudligi, ular qayerdan yaratilishi va kod relizga qanday yetib borishi haqidagi kelishuvi. Eng keng tarqalgan uchtasi:

• Git Flow — ko‘p uzoq yashovchi branch lar, versiyalar bo‘yicha relizlar. Relizlar kam bo‘lsa va bir nechta versiyani qo‘llab-quvvatlash kerak bo‘lsa, mos keladi.
• GitHub Flow — bitta asosiy branch va pull request orqali qo‘shiladigan qisqa feature branch lar. Ko‘pchilik veb-loyihalarga mos.
• Trunk-based development — hamma kichik o‘zgarishlarni to‘g‘ridan-to‘g‘ri asosiy branch ga tez-tez qo‘shadi. Yaxshi testlar, CI va feature flags ga ega jamoalarga mos.

Tanlov modaga emas, relizlar chastotasi, jamoa hajmi va avtomatlashtirish darajasiga bog‘liq.

Git Flow

Ikkita doimiy branch: main (production dagi kod) va develop (integratsiya). Qo‘shimcha ravishda: feature/*, release/*, hotfix/*.

main     ●──────────────●──────────●
          \            / \        /
release    \      ●──●   \      /
            \    /         hotfix
develop      ●──●──●──●──●──●
              \   /
feature        ●─●

Afzalliklari: reliz jarayoni tushunarli, bir nechta versiyani yuritish qulay (mobil ilovalar, qutili dasturlar, kutubxonalar).

Kamchiliklari: ko‘p merge va konfliktlar, o‘zgarishlar production ga uzoq yetib boradi, uzluksiz yetkazib berish bilan birlashtirish qiyin.

GitHub Flow

Bitta doimiy branch — main, u har doim deploy ga tayyor. Har qanday ish: qisqa branch, pull request, review, CI tekshiruvlari, merge, deploy.

main     ●───●───────●───●───────●
          \     /     \     /
feature    ●──●        ●──●

Afzalliklari: yangi xodimga tushuntirish oson, production gacha yo‘l qisqa, pull request orqali review jarayonga o‘rnatilgan.

Kamchiliklari: branch lar haftalab yashasa, konfliktlar qaytadi; relizni tayyorlash uchun alohida joy yo‘q, shuning uchun ishonchli CI zarur.

Trunk-based development

Barcha dasturchilar o‘zgarishlarni asosiy branch ga (trunk) tez-tez — kamida kuniga bir marta qo‘shadi. Branch lar bo‘lsa ham, ular kunlab emas, soatlab yashaydi.

main     ●─●─●─●─●─●─●─●─●─●
            \ /     \ /
             ●       ●      (bir necha soatlik branch lar)

Afzalliklari: konfliktlar minimal, kod doimo integratsiyalangan, istalgan paytda reliz qilish mumkin.

Kamchiliklari: intizom, yaxshi test qamrovi va tez CI talab qiladi. Ularsiz asosiy branch tez-tez buziladi.

Feature flags: trunk-based tugallanmagan vazifalar bilan qanday ishlaydi

Trunk-based ga asosiy savol: hali tayyor bo‘lmagan funksiyani main ga qanday qo‘shish mumkin? Javob — feature flags (funksiya bayroqlari).

Yangi funksiya kodi asosiy branch ga tushadi, lekin shart orqali yoqiladi:

if (flags.isEnabled("new-checkout", user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Bu nima beradi:

• Deploy relizdan ajratiladi. Kod allaqachon serverda, lekin foydalanuvchilar uni ko‘rmaydi.
• Bosqichma-bosqich ishga tushirish. Avval jamoa uchun, keyin foydalanuvchilarning bir qismi uchun, so‘ng hamma uchun yoqiladi.
• Tez orqaga qaytarish. Flag ni o‘chirish deploy ni orqaga qaytarishdan oson va tezroq.

To‘liq ishga tushirilgandan keyin flag larni o‘chirib tashlash kerak, aks holda kod hech kim eslamaydigan shartlar bilan to‘lib ketadi.

Taqqoslash

Qanday tanlash

1. Bir vaqtda bir nechta versiyani qo‘llab-quvvatlash kerakmi? Git Flow yoki release branch lari bilan soddalashtirilgan varianti.
2. Veb-mahsulot, haftasiga bir necha marta deploy, kichik jamoa? GitHub Flow.
3. Kuchli CI, tez testlar, feature flags ni joriy qilishga tayyorlik? Trunk-based.
4. Ikkilanyapsizmi? GitHub Flow dan boshlang va branch larni qisqa tuting — bu trunk-based ga tabiiy yo‘l.

Ko‘p uchraydigan xatolar

• Har kuni deploy qilinadigan sayt uchun Git Flow ni «shunday qabul qilingan» deb tanlash.
• Feature branch ni bir oy ushlab, keyin bir hafta konfliktlarni hal qilish.
• Avtotestlarsiz trunk-based ga o‘tish.
• Kodda o‘nlab eskirgan feature flags ni qoldirish.