GitHub Flow — soddaroq workflow, qachon mos keladi

~15 daq · Git · Professional Git Workflow

Muammodan boshlaylik

Kichik jamoa, veb-ilova. Gitflow ni joriy qildingiz (32-dars). Bir oydan keyin:

  • Kichik tuzatish production ga yetishi uchun: feature → develop → release → main — 4 bosqich, 3 kun
  • develop va main doimiy ravishda bir-biridan uzoqlashadi
  • Hotfix ni develop ga qo'shish yana unutildi
  • Hamma "qaysi branch dan boshlash kerak edi?" deb so'raydi

Veb-ilova uchun bu — ortiqcha. Saytni kuniga 10 marta yangilash mumkin, App Store ko'rib chiqishi yo'q. Kerak — soddaroq model. GitHub Flow.

GitHub Flow — bitta qoida

main dagi har bir narsa — deploy qilishga tayyor.

Bitta doimiy branch — main. Qolgan hamma narsa — undan chiqib, unga qaytadigan qisqa branch lar.

 main   ●─────●─────────●─────●───────────●─────●──→   (har bir merge = deploy)
         \   ↗           \   ↗             \   ↗
          ●─●             ●─●               ●─●
        feature/savat   fix/narx       feature/qidiruv

6 qadam

1. Branch yaratish — main dan

git switch main
git pull
git switch -c feature/mahsulot-qidiruvi

Nom — tavsifiy: nima qilinayotgani nomdan tushunarli bo'lsin.

2. Commitlar

Kichik, mantiqiy commitlar (8-dars). Tez-tez push qiling — zaxira va CI testlari uchun:

git push -u origin feature/mahsulot-qidiruvi

3. Pull Request ochish

Erta — hatto ish tugamagan bo'lsa ham (Draft PR, 23-dars). PR — muhokama joyi: "Shu yondashuv to'g'rimi?" degan savolni kod tayyor bo'lishidan oldin berish.

4. Review va muhokama

Jamoa ko'rib chiqadi, izoh qoldiradi; siz yangi commitlar push qilasiz. CI testlari har push da avtomatik ishlaydi (38-dars).

5. Deploy va tekshirish

Ko'p jamoalar merge dan oldin branch ni staging (yoki preview) muhitiga deploy qiladi. Vercel, Netlify kabi platformalar har bir PR uchun avtomatik preview URL yaratadi:

✅ Preview: https://dokon-git-feature-mahsulot-qidiruvi.vercel.app

Reviewerlar o'zgarishni brauzerda ko'radi.

6. Merge → avtomatik production

PR tasdiqlandi, testlar yashil → Merge → CI/CD main ni production ga deploy qiladi (39-dars). Branch o'chiriladi.

git switch main
git pull
git branch -d feature/mahsulot-qidiruvi

Hotfix — alohida jarayon yo'q

GitHub Flow da hotfix — shunchaki kichik branch:

git switch main && git pull
git switch -c fix/tolov-yaxlitlash
# tuzatish, push, PR, tez review, merge → deploy

main doim production holatida bo'lgani uchun develop ga qo'shish, teg qo'yish kabi qo'shimcha qadamlar yo'q. Muammo jiddiy bo'lsa — avval git revert (28-dars), keyin xotirjam tuzatish.

Muvaffaqiyat shartlari

GitHub Flow sodda — lekin bu soddalik bir qancha shartlarga tayanadi:

Shart Nima uchun
Avtomatik testlar (CI) main ga tushgan narsa darhol production ga ketadi — inson tekshiruvi yetmaydi
Avtomatik deploy (CD) Merge → deploy, qo'lda qadamlarsiz
Branch protection main ga to'g'ridan-to'g'ri push yo'q, PR + review + yashil testlar (23-dars)
Kichik PR lar Bir necha kunlik branch lar; katta PR — katta xavf
Tez rollback Revert yoki oldingi versiyani bir tugmada deploy qilish

Bular bo'lmasa — "main doim deploy ga tayyor" va'dasi bajarilmaydi.

Tayyor bo'lmagan funksiyalar — feature flags

Katta funksiya (masalan, yangi to'lov tizimi) 3 haftada tayyor bo'ladi. 3 haftalik branch — katta conflict lar. GitHub Flow javobi: kodni kichik qismlarda main ga qo'shish, lekin foydalanuvchidan yashirish:

if (featureFlags.yangiTolov && foydalanuvchi.betaTester) {
  return <YangiTolovFormasi />;
}
return <EskiTolovFormasi />;

Kod production da, lekin o'chirilgan. Tayyor bo'lganda — flag yoqiladi (avval 5% foydalanuvchiga, keyin hammaga). Muammo bo'lsa — flag o'chiriladi, deploy kerak emas.

Boshqa variantlar

Trunk-Based Development

GitHub Flow ning yanada qisqartirilgan shakli: branch lar bir kundan kam yashaydi, yoki dasturchilar to'g'ridan-to'g'ri main ("trunk") ga kichik commitlar qiladi. Kuchli testlar va feature flag lar talab qilinadi. Google, Meta kabi katta kompaniyalar shunday ishlaydi.

GitLab Flow

GitHub Flow + muhit branch lari: main → staging → production. Har bir muhitga merge orqali "ko'tariladi". Deploy vaqtini nazorat qilish kerak bo'lganda (masalan, faqat ish vaqtida).

Qaysi workflow ni tanlash

Loyiha Tavsiya
Veb-ilova, SaaS, uzluksiz deploy GitHub Flow
Shaxsiy loyiha, portfolio GitHub Flow (yoki shunchaki main + branch lar)
Mobil ilova (do'kon ko'rib chiqishi bilan) Gitflow yoki release branch lar bilan GitHub Flow
Kutubxona, bir nechta versiya qo'llab-quvvatlanadi Gitflow yoki main + release/X.x branch lar
Katta tajribali jamoa, kuchli CI Trunk-Based

Workflow — dogma emas. Eng yaxshisi — jamoangiz tushunadigan va rioya qiladigan soddaroq model. Uni CONTRIBUTING.md da yozib qo'ying.

Nima uchun shunday?

Nima uchun oddiyroq workflow ko'pincha yaxshiroq ishlaydi — Gitflow ko'proq nazorat bermaydimi?

Chunki xavf — o'zgarish hajmiga bog'liq, jarayon murakkabligiga emas. Gitflow da o'zgarishlar develop da haftalab to'planadi va relizda katta to'plam bo'lib production ga chiqadi — biror narsa buzilsa, 50 ta o'zgarishdan qaysi biri sabab ekanini topish qiyin. GitHub Flow da har bir kichik o'zgarish alohida, darhol chiqadi: muammo bo'lsa, sabab — oxirgi kichik PR, va uni bitta revert bilan bekor qilish mumkin. Kichik va tez-tez — katta va kam-kamdan xavfsizroq. Lekin buning sharti — testlar va avtomatlashtirish: ular Gitflow dagi qo'lda bosqichlar bajargan nazoratni o'z zimmasiga oladi.

Xulosa

Eslab qoling:

  • GitHub Flow: bitta doimiy branch — main doim deploy ga tayyor
  • 6 qadam: branch (main dan) → commitlar → PR → review + CI → (preview) deploy → merge
  • Hotfix — oddiy qisqa branch; jiddiy muammo — avval revert
  • Shartlar: avtomatik testlar, avtomatik deploy, branch protection, kichik PR lar
  • Tayyor bo'lmagan funksiyalar — feature flags
  • Trunk-Based — juda qisqa branch lar; GitLab Flow — muhit branch lari
  • Veb uchun — GitHub Flow; rejalashtirilgan relizlar uchun — Gitflow

Keyingi dars

34-dars: Conventional Commits — commit xabarlarini standartlashtirish