Hotfix Branch: bu nədir, necə yaradılır və mobil inkişafda tətbiqi

Müəllif: IT Sectr Dərc olunub: 2026-05-10 Oxuma vaxtı: 10 dəq

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 — istehsalatda kritik səhvlərin düzəldilməsi üçün təcili branch
  • Yaradılır əsas branch main/master-dan, develop-dan yox
  • Düzəlişdən sonra hotfix həm main, həm də develop ilə birləşdirilir
  • Git Flow — hotfix branch-lərini nəzərdə tutan əsas model
  • Yaşam müddəti hotfix minimaldır: yaradılmadan birləşməyə qədər — adətən saatlar

Hotfix Branch nədir?

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-in iş prinsipi

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 nə vaxt lazımdı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.

Branch modelləri və Hotfix-in yeri

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 və Hotfix

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.

XarakteristikaGit Flow-da HotfixGit Flow-da Feature
Hansı branch-danmaindevelop
Hara birləşirmain + developdevelop
Yaşam müddətisaatlargünlər / həftələr
Məzmunyalnız səhv düzəlişiyeni funksionallıq

GitHub Flow və Trunk-based

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 Branch necə yaradılı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.

Main-dan branch yaratmaq

İ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.

bash
# 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ş.

Düzəlişin qeydə alınması

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.

bash
# 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.

Main və develop ilə birləşdirmə

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.

bash
# 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-in Feature və Release-dən fərqi

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 StoreGoogle 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.

Hotfix ilə işdə tipik səhvlər

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.

  • Hotfix-in develop-dan yaradılması — hotfix develop-dan yaradılarsa, yamağa bitməmiş funksiyalar daxil ola bilər. Hotfix yalnız main-dan yaradılmalıdır ki, düzəlişdə yalnız stabil kod olsun.
  • Bir hotfix-də bir neçə düzəliş — hər bir düzəliş ayrıca hotfix branch-ında olmalıdır. Bir neçə səhvin bir branch-da qarışdırılması kod review-ni çətinləşdirir, reqressiya riskini artırır və lazım olduqda geri qaytarmağı çətinləşdirir.
  • Develop ilə birləşdirmənin buraxılması — hotfix develop ilə birləşdirilməzsə, düzəliş növbəti buraxılışda itiriləcək. Komanda eyni səhvin yenidən ortaya çıxdığını aşkar edəcək və onu yenidən düzəltməli olacaq.
  • Yanlış versiya teqi — hotfix yamaq artımı almalıdır (v2.3.0 → v2.3.1), minor (v2.4.0) və ya major (v3.0.0) yox. Semantik versiyalaşdırmanın pozulması qurma sistemini pozur və istifadəçiləri çaşdırır.
  • CI yoxlamalarının olmaması — hətta təcili hotfix avtomatik testlərdən keçməlidir. CI-nin buraxılması yeni səhvin daxil olma riskini artırır. Sürətləndirilmiş yoxlamalarla hotfix branch-ları üçün ayrıca pipeline olması tövsiyə olunur.

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 adi səhv düzəlişindən nə ilə fərqlənir?

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.

Komanda Git Flow istifadə etmirsə, hotfix yaratmaq olarmı?

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ə.

Hotfix-i Pull Request vasitəsilə təsdiqləmək lazımdırmı?

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.

Hotfix branch-ını necə adlandırmaq olar?

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.

Hotfix develop ilə ziddiyyət təşkil edərsə nə etməli?

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ə

  • Hotfix Branch — istehsalatda kritik səhvlərin düzəldilməsi üçün main-dan yaradılan təcili branch
  • Git Flow — hotfix-in feature və release ilə yanaşı daxili branch növü olduğu əsas branch modeli
  • Hotfix yaradılır yalnız main-dan və minimal sayda dəyişiklik ehtiva edir — yalnız nöqtəvi düzəliş
  • Düzəlişdən sonra hotfix həm main (teq ilə), həm də develop ilə birləşdirilir — düzəlişin itməməsi üçün
  • Hər hotfix bir problemi həll edir; bir branch-da bir neçə düzəlişin qarışdırılması riskləri artırır
  • Hətta təcili hotfix CI yoxlamalarından keçməlidir, baxmayaraq ki, pipeline sürətləndirilə bilər
  • Mobil tətbiqlər üçün hotfix xüsusilə vacibdir — App Store və Google Play-də moderasiya müddəti yamağın sürətli hazırlanmasını tələb edir

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.

Layihəni müzakirə et

Həm də oxuyun