Git Flow: nədir, budaqlanma modeli və layihələrdə istifadəsi

Git Flow nədir?

Git Flow — inkişaf, buraxılış və düzəlişləri idarə etmək üçün budaqların və birləşmə qaydalarının ciddi strukturunu təyin edən Git budaqlanma modelidir. Vincent Driessen 2010-cu ilin yanvarında "A successful Git branching model" məqaləsini dərc etdi və o vaxtdan bəri Git Flow korporativ Java və .NET inkişafında de-fakto standarta çevrildi. Əsas ideya — kodu müxtəlif sabitlik səviyyələri olan beş növ budağa bölməkdir.

Atlassian Git Tutorials, 2024-ə görə, Git Flow iki daimi budağa əsaslanır: main (əvvəllər master) və develop. Bütün digər budaqlar müvəqqətidir: feature, release, hotfix. Hər budaq növünün dəqiq müəyyən edilmiş həyat dövrü və birləşmə qaydaları var. Mobil inkişafda Git Flow müntəzəm buraxılış dövrləri (2–4 həftə) və çoxsaylı versiyaları dəstəkləyən layihələrdə tətbiq olunur.

Git Flow sadə modellərdən (GitHub Flow) fərqlənir, çünki inteqrasiya üçün ayrıca develop budağı tələb edir. Bu, birləşmə prosesinə bir addım əlavə edir, lakin bitməmiş xüsusiyyətlərin buraxılışa hazır koddan əlavə izolyasiyasını təmin edir.

Vincent Driessen və Git Flow tarixi

2010-cu ildə Vincent Driessen "A successful Git branching model" adlı məqalə dərc etdi və bu, Git tarixində ən çox istinad edilən məqalələrdən biri oldu. Model sabit buraxılışları və paralel versiya dəstəyi olan bir layihə üçün yaradılmışdır. 2020-ci ildə Driessen etiraf etdi ki, Git Flow müasir CI/CD təcrübələri üçün köhnəlmişdir, lakin model uzun buraxılış dövrü və köhnə versiyaları dəstəkləmək zərurəti olan layihələr üçün aktual olaraq qalır.

# Git Flow-un işə salınması
git flow init

# Feature budağının yaradılması
git flow feature start "add-auth"

# Feature budağının tamamlanması (develop-a birləşdirmə)
git flow feature finish "add-auth"

# Release-in yaradılması
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main budağı: buraxılış kodu və teqləmə

Main (əvvəllər master) — yalnız yerləşdirməyə hazır buraxılış kodunu ehtiva edən əsas budaq. Main-dəki hər commit, semantik versiyalama formatında teqlə qeyd olunmuş müəyyən bir məhsul versiyasına uyğun olmalıdır, məsələn v1.0.0, v1.1.0. Main-də heç bir birbaşa inkişaf aparılmır — dəyişikliklər bura yalnız release və ya hotfix budaqları vasitəsilə daxil olur.

semver.org, 2024-ə görə, main-dəki teqlər MAJOR.MINOR.PATCH formatından istifadə edir. MAJOR — API-də uyğun olmayan dəyişikliklər, MINOR — geriyə uyğun funksionallığın əlavə edilməsi, PATCH — səhvlərin düzəldilməsi zamanı artırılır. Git Flow-da hər finish release avtomatik olaraq main-də versiya teqi ilə commit yaradır.

Main budağı — istehsala yerləşdirilən yeganə budaqdır. Mobil layihələr üçün bu o deməkdir ki, main-ə push edildikdə App Bundle və ya IPA qurma və Google Play / App Store-da dərc etmə pipeline-ı işə düşür. GitLab CI/CD parametrlərində main force-push və silinmədən qorunur.

Semantik versiyalama və teqlər

Main-dəki hər commit SemVer formatında teqlə müşayiət olunur: vMAJOR.MINOR.PATCH. MAJOR — API-də uyğun olmayan dəyişikliklər üçün, MINOR — geriyə uyğun yeni funksionallıq üçün, PATCH — səhvlərin düzəldilməsi üçün. Nümunə: v2.1.0 — səhv düzəlişləri olmayan yeni xüsusiyyətləri olan ikinci əsas buraxılış deməkdir. Git Flow-da teqlər avtomatik olaraq git flow release finish əmri ilə release və ya hotfix tamamlandıqda yaradılır.

Develop budağı: inteqrasiya inkişaf xətti

Develop — bütün tamamlanmış xüsusiyyətlərin inteqrasiyası üçün nəzərdə tutulmuş Git Flow-un ikinci daimi budağı. Tərtibatçılar kod nəzərdən keçirmə və CI/CD yoxlamalarından keçdikdən sonra feature budaqlarını develop-a birləşdirirlər. Develop cari sprintin bütün həyata keçirilmiş xüsusiyyətlərini əhatə edən ən son sabit kod versiyasını ehtiva edir.

DataSift Git Flow Guide, 2024-ə görə, develop tamamlanmamış inteqrasiyalar səbəbindən müvəqqəti olaraq qeyri-sabit ola bilər. Problemlərin qarşısını almaq üçün komandalar Continuous Integration (CI) tətbiq edir: hər xüsusiyyət develop-a birləşmədən əvvəl tam test dəstindən keçir. CI uğursuz olarsa — tərtibatçı növbəti birləşməyə qədər kodu düzəldir. Develop həmişə main-in cari versiyasına bağlıdır: buraxılışdan dərhal sonra develop main ilə birləşmə vasitəsilə sinxronlaşdırılır.

Feature budaqları: yeni funksionallığın inkişafı

Feature budaqları — ayrı-ayrı xüsusiyyətlərin, səhv düzəlişlərinin və ya təcrübələrin inkişafı üçün müvəqqəti budaqlar. Hər feature budağı develop-dan yaradılır və tamamlandıqdan sonra develop-a geri birləşdirilir. Feature budağının adı adətən tapşırıq nömrəsini və ya qısa təsviri ehtiva edir: feature/APP-123-add-oauth, feature/redesign-profile. Git Flow-da feature budaqları limitsiz müddət ərzində mövcud ola bilər.

Pro Git Book, 2024-ə görə, feature budaqları izolyasiya olunmuş inkişaf mühitidir: bir budaqdakı dəyişikliklər birləşmə anına qədər digərlərinə təsir etmir. Mobil layihələrdə feature budaqları böyük konfliktlərin qarşısını almaq üçün rebase və ya merge vasitəsilə develop ilə sinxronlaşdırılır. MR yaratmazdan əvvəl feature budağını develop üzərində rebase etmək tövsiyə olunur.

# Feature budağının əl ilə yaradılması (git flow olmadan)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# GitLab-da CLI vasitəsilə MR yaradılması
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release budaqları: buraxılışın hazırlanması

Release budaqları — buraxılışı hazırlamaq üçün develop-dan yaradılan müvəqqəti budaqlar. Develop yeni versiya üçün kifayət qədər xüsusiyyət dəsti ehtiva etdikdə, komanda release/X.Y.Z budağını yaradır (məsələn, release/2.1.0). Bu budaqda yalnız son düzəlişlər edilir: versiyanın artırılması, lokallaşdırmanın yenilənməsi, son test, kritik səhvlərin düzəldilməsi.

Atlassian Git Tutorials, 2024-ə görə, release budağı əsas problemi həll edir: son düzəlişlərin paralel inkişafdan izolyasiyası. Release çıxmağa hazırlaşarkən, develop-da növbəti buraxılış üçün yeni xüsusiyyətlər birləşdirilməyə davam edir. Tamamlandıqdan sonra release budağı main-ə (teqlə) və develop-a (versiya artımını sinxronlaşdırmaq üçün) birləşdirilir.

Hotfix budaqları: istehsalda təcili düzəlişlər

Hotfix budaqları — istehsalda kritik səhvlərin təcili düzəldilməsi üçün müvəqqəti budaqlar. Git Flow-un develop-dan deyil, main-dən yaradılan yeganə budaq növüdür. Ad formatı: hotfix/X.Y.Z+1 (məsələn, hotfix/2.1.1). Tamamlandıqdan sonra hotfix budağı eyni anda həm main-ə (yeni yamaq buraxılışı kimi), həm də develop-a (düzəlişin növbəti buraxılışlarda itməməsi üçün) birləşdirilir.

DataSift Git Flow Guide, 2024-ə görə, hotfix budaqları mümkün qədər qısa olmalıdır — yalnız düzəliş və test. Hotfix yeni xüsusiyyətlər və ya refaktorinq daxil etməməlidir. Mobil inkişafda hotfix kritik çökmələrin (crash rate > 0.1%), təhlükəsizlik zəifliklərinin və ya App Store-da bloklayan səhvlərin düzəldilməsi üçün tətbiq olunur.

Git Flow-un mobil inkişaf üçün üstünlükləri və çatışmazlıqları

Git Flow xüsusilə böyük komandalar və müntəzəm buraxılışları olan layihələr üçün faydalı olan aydın struktur təmin edir. Üstünlüklər: bitməmiş xüsusiyyətlərin feature budaqlarında izolyasiyası, inkişafı bloklamadan buraxılışın hazırlanması imkanı, hotfix vasitəsilə çoxsaylı versiyaların dəstəklənməsi. Çatışmazlıqlar: yeni başlayanlar üçün mürəkkəblik, feature budaqlarının müntəzəm rebase ehtiyacı, uzunömürlü budaqlarda konfliktlər.

Martin Fowler, 2024-ə görə, Git Flow-un əsas çatışmazlığı uzunömürlü feature budaqlarıdır. Xüsusiyyət 2+ həftə develop ilə sinxronlaşdırılmadan inkişaf etdirilərsə, birləşmə zamanı konflikt əhəmiyyətli olur. Mobil layihələr üçün feature budağını hər gün develop üzərində rebase vasitəsilə sinxronlaşdırmaq tövsiyə olunur.

Git Flow Continuous Deployment (hər commit main-ə → istehsala) olan layihələr üçün tövsiyə edilmir. Belə layihələr üçün GitHub Flow və ya Trunk-Based Development daha sadə və sürətli model təmin edir. Lakin buraxılış dövrləri və köhnə versiyaların dəstəyi olan layihələr üçün Git Flow optimal seçim olaraq qalır.

Git Flow komanda üçün nə vaxt zərərlidir

Git Flow üç halda problem yaradır: komanda 5 nəfərdən azdırsa (həddindən artıq mürəkkəblik), Continuous Deployment (çatdırılma gecikməsi), rebase intizamının olmaması (uzunömürlü feature budaqları birləşmə konfliktləri yaradır). Komanda vaxtının 20%-dən çoxunu budaqların birləşdirilməsinə və konfliktlərin həllinə sərf edirsə — Git Flow hətta böyük komanda üçün də uyğun deyil.

Git Flow alternativləri: GitHub Flow və Trunk-Based Development

Git Flow alternativləri CI/CD tətbiq edən komandalar üçün daha sadə proses təklif edir. GitHub Flow yalnız bir daimi budaq (main) və feature budaqlarından istifadə edir. Hər xüsusiyyət main-dən yaradılır, nəzərdən keçirmə və CI-dən sonra main-ə geri birləşdirilir və dərhal yerləşdirilir. GitHub Flow daha sadədir, lakin bitməmiş xüsusiyyətlərin izolyasiyasını və paralel buraxılış hazırlığını dəstəkləmir.

GitHub Docs, 2024-ə görə, Trunk-Based Development (TBD) daha da irəli gedir: bütün tərtibatçılar bir budaqda (trunk) işləyir, 1–2 günlük qısaömürlü feature budaqlarından istifadə edirlər. Feature toggles (xüsusiyyət bayraqları) bitməmiş kodun görünməsini idarə edir. TBD yüksək CI/CD intizamı və test avtomatlaşdırması tələb edir.

• GitHub Flow — bir main + feature budaqları, CI/CD və kiçik komandalar üçün idealdır
• GitLab Flow — mühit budaqları (staging, production) ilə Git Flow-u inkişaf etdirir
• Trunk-Based Development — bir budaq + feature toggles, maksimum CI/CD, minimum birləşmə
• One Flow — develop budağı olmayan sadələşdirilmiş Git Flow, yalnız main + feature + release