Hotfix Branch: bu nima, qanday yaratiladi va mobil ishlanmada qo'llaniladi

Hotfix Branch nima?

Hotfix Branch — bu ishlayotgan ishlab chiqarish muhitidagi kritik nuqsonlarni tezkor tuzatish uchun yaratiladigan vaqtinchalik Git branch-idir. Feature branch-laridan farqli o'laroq, ular develop-dan ajraladi va bir necha kun yoki hafta yashaydi, hotfix esa main/master-dan yaratiladi va bug-ni tuzatish uchun qancha kerak bo'lsa, shuncha mavjud bo'ladi.

Hotfix-ning asosiy vazifasi — kritik xatoni aniqlash va uni ishlab chiqarishda tuzatish o'rtasidagi vaqtni minimallashtirishdir. Jamoa joriy sprint yoki reliz siklini kutmaydi, balki yamoqni darhol chiqaradi. Bu, ayniqsa, mobil ilovalar uchun muhim, chunki kritik bug foydalanuvchilarni bloklashi va ularning ketishiga olib kelishi mumkin.

Google Play Console ma'lumotlariga ko'ra, Google Play-da yangilanishni moderatsiya qilishning o'rtacha vaqti 2 soatdan 24 soatgacha. App Store uchun ekspress ko'rib chiqish 1 soatdan 4 soatgacha davom etishi mumkin. Hotfix branch-lari moderatsiya tugashidan oldin tuzatish tayyorlash va tasdiqlashdan so'ng darhol uni chiqarish imkonini beradi.

Hotfix ishlash printsipi

Hotfix jarayoni uch bosqichdan iborat: main-dan branch yaratish, tuzatish kiritish va main va develop-ga qayta birlashtirish. Oddiy tuzatishdan asosiy farq — hotfix har doim ikkala branch bilan birlashtiriladi, shunda tuzatish keyingi relizda yo'qolmaydi.

Jamoa hotfix-ga yangi funksionallik yoki refaktoring qo'shmasligi kerak. Faqat kritik muammoni bartaraf etish uchun minimal zarur bo'lgan nuqtali tuzatish. Bu qoidadan har qanday chetga chiqish regressiya xavfini oshiradi va yamoqni chiqarish vaqtini uzaytiradi.

Qachon Hotfix kerak

Hotfix uch stsenariyda zarur: kritik bug foydalanuvchilarni bloklaydi (crash, ma'lumot yo'qolishi), xavfsizlik zaifligi zudlik bilan yopilishni talab qiladi yoki kritik biznes mantig'i buzilgan (to'lovlar, avtorizatsiya). Agar bug kritik bo'lmasa — uni oddiy reliz sikli doirasida develop orqali tuzatish mumkin.

Mobil ilovalar uchun hotfix, shuningdek, server o'zgarishlarini ham o'z ichiga olishi mumkin, agar arxitektura funksiyalarni masofadan o'zgartirishga imkon bersa (feature flags). Bunday holda, hotfix branch-i minimal bo'lishi mumkin yoki agar tuzatish server tomonida amalga oshirilsa, umuman kerak bo'lmasligi mumkin.

Branch modellari va Hotfix o'rni

Barcha branch modellari hotfix branch-larini qo'llab-quvvatlamaydi. An'anaviy Git Flow hotfix-ni to'liq huquqli branch turi sifatida nazarda tutadi, zamonaviyroq yondashuvlar (GitHub Flow, Trunk-based) esa shoshilinch tuzatishlar masalasini boshqacha hal qiladi.

Git Flow va Hotfix

Git Flow — hotfix feature va release bilan bir qatorda o'rnatilgan branch turi bo'lgan yagona modeldir. Git Flow-da hotfix main-dan yaratiladi va tugagandan so'ng ham main (versiya tegi bilan), ham develop bilan birlashtiriladi. Bu tuzatishning keyingi relizda yo'qolmasligini kafolatlaydi.

GitHub Flow va Trunk-based

GitHub Flow hotfix uchun alohida branch turidan foydalanmaydi. Buning o'rniga, dasturchi main-dan oddiy feature branch yaratadi, tuzatish kiritadi va Pull Request ochadi. Ko'rib chiqish va CI tekshiruvlaridan so'ng branch main bilan birlashtiriladi va darhol joylashtiriladi. Afzalligi — soddalik, kamchiligi — shoshilinch tuzatishlar uchun alohida kanalning yo'qligi.

Trunk-based ishlanma hotfix masalasini to'g'ridan-to'g'ri main-ga commit-lar (kritik holatlar uchun) va majburiy postfaktum ko'rib chiqish orqali hal qiladi. Bu yondashuv yuqori jamoa intizomi va ishonchli avtomatik testlarni talab qiladi, chunki o'zgarishlar darhol ishlab chiqarishga tushadi.

Hotfix Branch qanday yaratiladi

Hotfix yaratish asosiy branch-ga o'tish va hotfix/ prefiksi bilan yangi branch yaratish bilan boshlanadi. Mobil ilovadagi kritik bug-ni tuzatish misolida bosqichma-bosqich jarayonni ko'rib chiqaylik.

Main-dan branch yaratish

Birinchi qadam — main-ga o'ting va branch-ning dolzarbligiga ishonch hosil qiling. So'ngra tuzatish mohiyatini aks ettiruvchi tushunarli nom bilan hotfix branch yarating.

# Main-ga o'ting va eng so'nggi o'zgarishlarni oling
git checkout main
git pull origin main

# Hotfix branch yarating
git checkout -b hotfix/crash-on-login

Branch yaratilgandan so'ng tuzatish kiritilishi mumkin. Muhim: hotfix minimal miqdordagi o'zgarishlarni o'z ichiga olishi kerak. Kodni refaktoring qilish yoki yangi imkoniyatlar qo'shish mumkin emas — faqat muammoni bartaraf etuvchi nuqtali tuzatish.

Tuzatishni qayd etish

Commit hotfix-da muammo va uning yechimini aniq tavsiflovchi ma'lumot beruvchi xabarga ega bo'lishi kerak. Format: tur(soha): qisqa tavsif + trackerdagi topshiriqqa havola.

# O'zgartirilgan fayllarni qo'shing
git add src/ui/login/LoginActivity.kt

# Tavsif bilan commit yarating
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

Commit xabari muammo tavsifini va topshiriqqa havolani o'z ichiga olishi kerak. Bu tarixda qidirishni osonlashtiradi va hamkasblarga nima tuzatilgani va nima uchun tuzatilganini tushunishga yordam beradi. Mobil loyihalarda odatda bug topilgan ilova versiyasi ham ko'rsatiladi.

Main va develop bilan birlashtirish

Yakuniy qadam — hotfix-ni main-ga (yangi yamoq versiyasi tegi bilan) va develop-ga (keyingi relizda tuzatish saqlanishi uchun) qayta birlashtiring. Avval main bilan teg bilan birlashma, so'ng develop bilan birlashma yaratiladi.

# Main bilan birlashtiring va teg yarating
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Develop bilan birlashtiring
git checkout develop
git merge --no-ff hotfix/crash-on-login

# O'zgarishlarni serverga yuboring
git push origin main --tags
git push origin develop

--no-ff flag-i, hotfix fast-forward orqali qo'llanilishi mumkin bo'lsa ham, birlashma commit yaratilishini kafolatlaydi. Bu shoshilinch tuzatish amalga oshirilganligi haqidagi ma'lumotni saqlaydi va kelajakda tarix tahlilini osonlashtiradi.

Hotfix-ni Feature va Release-dan farqi

Hotfix feature va release branch-laridan maqsad, hayot davomiyligi va birlashish qoidalari bo'yicha tubdan farq qiladi. Bu farqlarni tushunish jamoada Git jarayonlarini to'g'ri tashkil etish uchun juda muhimdir.

Feature branch yangi funksionallik uchun mo'ljallangan. Bir necha kundan bir necha haftagacha yashaydi, develop-dan yaratiladi va develop-ga qayta birlashtiriladi. Feature keyinchalik squash yoki rebase orqali siqiladigan ko'plab commit-larni, shu jumladan eksperimental bo'lganlarni o'z ichiga olishi mumkin.

Release branch relizni chiqarishga tayyorlaydi. Develop-dan yaratiladi, unda barqarorlashtirish jarayonida topilgan bug-lar tuzatiladi va yangi funksionallik qabul qilinmaydi. Tugagandan so'ng release main (teg bilan) va develop bilan birlashtiriladi.

Hotfix esa to'g'ridan-to'g'ri main-dan yaratiladi va birlashtiriladi, develop-ni chetlab o'tib (tuzatishdan so'ng develop bilan ham sinxronlashsa ham). Minimal miqdordagi o'zgarishlarni o'z ichiga oladi va minimal vaqt mavjud bo'ladi. Agar feature yoki release keyingi siklgacha qoldirilishi mumkin bo'lsa, hotfix — qoldirilmaydi.

Mobil ishlanma uchun bu farq ayniqsa muhim: App Store va Google Play yamoq versiyalarini asosiy relizlardan alohida chiqarishga imkon beradi. Hotfix branch yamoq relizining tugallanmagan funksiyalar bilan aralashmasligini ta'minlaydi.

Hotfix bilan ishlashda tipik xatolar

Xatolar hotfix bilan ishlashda shoshilinch tuzatishning afzalliklarini inkor etishi mumkin. Git Flow-dan foydalanadigan jamoalarda eng ko'p uchraydigan besh muammoni ko'rib chiqaylik.

• Hotfix-ni develop-dan yaratish — agar hotfix develop-dan yaratilsa, yamoqqa tugallanmagan funksiyalar kirishi mumkin. Hotfix faqat main-dan yaratilishi kerak, shunda tuzatish faqat barqaror kodni o'z ichiga oladi.
• Bir hotfix-da bir nechta tuzatish — har bir tuzatish alohida hotfix branch-da bo'lishi kerak. Bir nechta bug-larni bitta branch-da aralashtirish kod ko'rib chiqishni qiyinlashtiradi, regressiya xavfini oshiradi va kerak bo'lganda qaytarishni qiyinlashtiradi.
• Develop bilan birlashtirishni o'tkazib yuborish — agar hotfix develop bilan birlashtirilmasa, tuzatish keyingi relizda yo'qoladi. Jamoa xuddi shu bug yana paydo bo'lganini aniqlaydi va uni qayta tuzatishga majbur bo'ladi.
• Noto'g'ri versiya tegi — hotfix yamoq o'sishini olishi kerak (v2.3.0 → v2.3.1), minor (v2.4.0) yoki major (v3.0.0) emas. Semantik versiyalashning buzilishi qurish tizimini buzadi va foydalanuvchilarni chalg'itadi.
• CI tekshiruvlarining yo'qligi — hatto shoshilinch hotfix ham avtomatik testlardan o'tishi kerak. CI-ni o'tkazib yuborish yangi xato kiritish xavfini oshiradi. Tezlashtirilgan tekshiruvlar bilan hotfix branch-lari uchun alohida pipeline bo'lishi tavsiya etiladi.

Bu xatolarning har biri yamoqni chiqarishning kechikishiga yoki ishlab chiqarishda yangi muammolar paydo bo'lishiga olib keladi. Jamoalar hotfix bilan ishlash qoidalarini CONTRIBUTING.md da belgilab olishlari va ularni CI/CD tekshiruvlari orqali avtomatlashtirishlari kerak.