Hotfix Branch — bu, Git-də istehsalat mühitində kritik səhvlərin təcili düzəldilməsi üçün nəzərdə tutulmuş branch növüdür. Adi branch-lərdən fərqli olaraq, hotfix birbaşa əsas branch-dan (main/master) yaradılır və düzəlişdən sonra eyni anda həm main, həm də develop ilə birləşdirilir. Atlassian, 2025 məlumatlarına görə, Git Flow modeli hotfix branch-ləri ilə ciddi buraxılış qaydaları ilə işləyən komandaların 67%-də istifadə olunur.
Əsas məqamlar
Hotfix Branch — bu, işləyən istehsalat mühitində kritik qüsurların operativ düzəldilməsi üçün yaradılan müvəqqəti Git branch-dır. Feature branch-lərindən fərqli olaraq, onlar develop-dan ayrılır və bir neçə gün və ya həftə yaşayır, hotfix isə main/master-dan yaradılır və səhvin düzəldilməsi üçün nə qədər lazımdırsa, o qədər mövcud olur.
Hotfix-in əsas vəzifəsi — kritik səhvin aşkarlanması ilə onun istehsalatda düzəldilməsi arasında vaxtı minimuma endirməkdir. Komanda cari sprint və ya buraxılış dövrünün bitməsini gözləmir, dərhal yamaq buraxır. Bu, xüsusilə mobil tətbiqlər üçün vacibdir, çünki kritik səhv istifadəçiləri bloklaya və onların axınına səbəb ola bilər.
Google Play Console məlumatlarına görə, Google Play-də yeniləmə moderasiyasının orta müddəti 2 saatdan 24 saata qədərdir. App Store üçün ekspress review 1 saatdan 4 saata qədər çəkə bilər. Hotfix branch-ləri moderasiya başa çatmamış düzəliş hazırlamağa və təsdiqdən dərhal sonra onu yayımlamağa imkan verir.
Hotfix prosesi üç addımdan ibarətdir: main-dan branch yaratmaq, düzəliş etmək və main və develop-a geri birləşdirmək. Adi düzəlişdən əsas fərq — hotfix həmişə hər iki branch-a birləşdirilir ki, növbəti buraxılışda düzəliş itməsin.
Komanda hotfix-ə yeni funksionallıq və ya refaktorinq əlavə etməməlidir. Yalnız kritik problemi aradan qaldırmaq üçün minimal zəruri olan nöqtəvi düzəliş. Bu qaydadan hər hansı bir kənarlaşma reqressiya riskini artırır və yamağın buraxılma müddətini uzadır.
Hotfix üç ssenaridə lazımdır: kritik səhv istifadəçiləri bloklayır (crash, məlumat itkisi), təhlükəsizlik zəifliyi dərhal bağlanma tələb edir və ya kritik biznes məntiqi sındırılıb (ödənişlər, autorizasiya). Əgər səhv kritik deyilsə — onu adi buraxılış dövrü çərçivəsində develop vasitəsilə düzəltmək olar.
Mobil tətbiqlər üçün hotfix həmçinin server dəyişikliklərini də əhatə edə bilər, əgər arxitektura funksiyaları uzaqdan dəyişməyə imkan verirsə (feature flags). Bu halda hotfix branch-ı minimal ola bilər və ya ümumiyyətlə lazım olmaya bilər, əgər düzəliş server tərəfində aparılırsa.
Bütün branch modelləri hotfix branch-lərini dəstəkləmir. Ənənəvi Git Flow hotfix-i tam hüquqlu branch növü kimi nəzərdə tutur, daha müasir yanaşmalar (GitHub Flow, Trunk-based) isə təcili düzəlişlər məsələsini fərqli həll edir.
Git Flow — hotfix-in feature və release ilə yanaşı daxili branch növü olduğu yeganə modeldir. Git Flow-da hotfix main-dan yaradılır və tamamlandıqdan sonra həm main (versiya teqi ilə), həm də develop ilə birləşdirilir. Bu, düzəlişin növbəti buraxılışda itməyəcəyinə zəmanət verir.
| Xarakteristika | Git Flow-da Hotfix | Git Flow-da Feature |
|---|---|---|
| Hansı branch-dan | main | develop |
| Hara birləşir | main + develop | develop |
| Yaşam müddəti | saatlar | günlər / həftələr |
| Məzmun | yalnız səhv düzəlişi | yeni funksionallıq |
GitHub Flow hotfix üçün ayrıca branch növündən istifadə etmir. Bunun əvəzinə, tərtibatçı main-dan adi feature branch-ı yaradır, düzəliş edir və Pull Request açır. Review və CI yoxlamalarından sonra branch main ilə birləşdirilir və dərhal yayımlanır. Üstünlüyü — sadəlik, çatışmazlığı — təcili düzəlişlər üçün ayrıca kanalın olmamasıdır.
Trunk-based inkişaf hotfix məsələsini birbaşa main-a commit-lər (kritik hallar üçün) və məcburi postfaktum review vasitəsilə həll edir. Bu yanaşma yüksək komanda intizamı və etibarlı avtomatik testlər tələb edir, çünki dəyişikliklər dərhal istehsalata düşür.
Hotfix yaratmaq əsas branch-a keçid və hotfix/ prefiksi ilə yeni branch yaratmaqla başlayır. Mobil tətbiqdə kritik səhvin düzəldilməsi nümunəsində addım-addım prosesə baxaq.
İlk addım — main-a keçin və branch-ın aktual olduğundan əmin olun. Sonra düzəlişin mahiyyətini əks etdirən anlaşıqlı adla hotfix branch-ı yaradın.
# Main-a keç və ən son dəyişiklikləri əldə et
git checkout main
git pull origin main
# Hotfix branch-ı yarat
git checkout -b hotfix/crash-on-login
Branch yaradıldıqdan sonra düzəliş edilə bilər. Hotfix minimal sayda dəyişiklik ehtiva etməlidir. Kodu refaktorinq etmək və ya yeni imkanlar əlavə etmək olmaz — yalnız problemi aradan qaldıran nöqtəvi düzəliş.
Commit hotfix-də problemi və onun həllini birmənalı təsvir edən məlumatlandırıcı mesaj olmalıdır. Format: tip(sahə): qısa təsvir + tracker-də tapşırığa keçid.
# Dəyişdirilmiş faylları əlavə et
git add src/ui/login/LoginActivity.kt
# Təsvirlə commit yarat
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 mesajı problemin təsvirini və tapşırığa keçidi ehtiva etməlidir. Bu, tarixçədə axtarışı asanlaşdırır və həmkarlara nəyin düzəldildiyini və niyə düzəldildiyini anlamağa kömək edir. Mobil layihələrdə adətən səhvin aşkarlandığı tətbiq versiyası da göstərilir.
Son addım — hotfix-i main-a (yeni yamaq versiyası teqi ilə) və develop-a (növbəti buraxılışda düzəlişin qorunması üçün) geri birləşdirin. Əvvəlcə main ilə teq ilə birləşmə, sonra develop ilə birləşmə yaradılır.
# Main ilə birləşdir və teq yarat
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"
# Develop ilə birləşdir
git checkout develop
git merge --no-ff hotfix/crash-on-login
# Dəyişiklikləri serverə göndər
git push origin main --tags
git push origin develop
--no-ff flag-ı, hotfix fast-forward vasitəsilə tətbiq oluna bilsə belə, birləşmə commit-inin yaradılmasına zəmanət verir. Bu, təcili düzəlişin edildiyi haqqında məlumatı qoruyur və gələcəkdə tarixçənin təhlilini asanlaşdırır.
Hotfix feature və release branch-lərindən məqsəd, yaşam müddəti və birləşmə qaydalarına görə prinsipial olaraq fərqlənir. Bu fərqləri başa düşmək komandada Git proseslərini düzgün təşkil etmək üçün kritik əhəmiyyət daşıyır.
Feature branch-ı yeni funksionallıq üçün nəzərdə tutulub. Bir neçə gündən bir neçə həftəyə qədər yaşayır, develop-dan yaradılır və develop-a geri birləşdirilir. Feature sonradan squash və ya rebase vasitəsilə sıxılan çoxlu commit-lər, o cümlədən eksperimental olanları ehtiva edə bilər.
Release branch-ı buraxılışı hazırlayır. Develop-dan yaradılır, stabilləşmə prosesində tapılan səhvlər düzəldilir və yeni funksionallıq qəbul etmir. Tamamlandıqdan sonra release main (teq ilə) və develop ilə birləşdirilir.
Hotfix isə birbaşa main-dan yaradılır və birləşdirilir, develop-ı keçərək (baxmayaraq ki, düzəlişdən sonra develop ilə də sinxronlaşır). Minimal sayda dəyişiklik ehtiva edir və minimal müddət mövcud olur. Əgər feature və ya release növbəti dövrə qədər təxirə salına bilərsə, hotfix — salına bilməz.
Mobil inkişaf üçün bu fərq xüsusilə vacibdir: App Store və Google Play yamaq versiyalarını əsas buraxılışlardan ayrıca buraxmağa imkan verir. Hotfix branch-ı yamaq buraxılışının bitməmiş funksiyalarla qarışmamasını təmin edir.
Səhvlər hotfix ilə işdə təcili düzəlişin üstünlüklərini inkar edə bilər. Git Flow istifadə edən komandalarda ən çox rast gəlinən beş problemi nəzərdən keçirək.
Bu səhvlərin hər biri yamağın buraxılmasının gecikməsinə və ya istehsalatda yeni problemlərin yaranmasına gətirib çıxarır. Komandalar hotfix ilə iş qaydalarını CONTRIBUTING.md-də təsbit etməli və onları CI/CD yoxlamaları vasitəsilə avtomatlaşdırmalıdır.
Tez-tez verilən suallar
Hotfix istehsalatda kritik səhvi düzəldir və main-dan yaradılır, adi səhv düzəlişi isə develop-da səhvi düzəldir və növbəti planlı buraxılışa daxil ediləcək. Hotfix dərhal yamaq versiyasının buraxılmasını tələb edir.
Bəli, hotfix istənilən branch modelində yaradıla bilər. GitHub Flow-da bunun üçün main-dan adi feature branch-ı və sonra Pull Request vasitəsilə Merge istifadə olunur. Trunk-based-da — birbaşa main-a commit məcburi postfaktum review ilə.
Arzuolunandır, lakin sürətləndirilmiş review-ə icazə verilir. Kritik səhvlər üçün “approve after merge” mexanizmindən istifadə etmək olar — hotfix əvvəlcə birləşdirilir, review isə postfaktum aparılır. Əsas odur ki, belə bir qayda komanda qaydalarında təsbit edilsin.
Format: hotfix/qısa-problem-təsviri. Məsələn: hotfix/null-pointer-auth, hotfix/crash-on-payment. Ad komandanın bütün üzvləri üçün anlaşıqlı olmalı və tracker-də tapşırıq nömrəsini ehtiva etməlidir.
Ziddiyyəti həll edin develop ilə birləşdirmə zamanı adi merge-də olduğu kimi. Əgər ziddiyyət əhəmiyyətlidirsə — ola bilər ki, develop-da eyni sahəyə toxunan dəyişikliklər olub. Bu halda düzəlişin yeni kodla düzgün işlədiyinə əmin olmaq vacibdir.
Nəticə
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun