Git-də Main və Master Branch: bu nədir, əsas filial nə üçün lazımdır

Git-də Main / Master Branch nədir

Main Branch (və ya Master — depo parametrlərindən asılı olaraq) — hər hansı Git deposunun inisiallaşdırılması zamanı yaradılan defolt filialdır. Layihənin əsas filialıdır və istehsala yerləşdirməyə hazır kodu ehtiva edir.

Gündəlik işin yeni funksiyalarla qaynadığı develop-dən fərqli olaraq, main layihənin vitrinidir. Main-dəki kodun hər versiyası tam dövr keçib: feature filialında inkişaf, develop-da inteqrasiya, release filialında buraxılış hazırlığı və yekun sınaq. Yalnız bundan sonra dəyişikliklər main-ə daxil olur.

Əsas prinsip: main həmişə stabil olmalıdır. Main-də xəta aşkar edilərsə, bu, növbədənkənar buraxılmalı olan təcili hotfix deməkdir. Buna görə peşəkar layihələrdə main branch protection rules ilə təsadüfi dəyişikliklərdən qorunur.

Git Book-a görə, main xüsusi xassələri olan filial deyil, konvensiyaya görə əsas hesab edilən adi commit istinadıdır. Git sistem səviyyəsində main ilə hər hansı digər filial arasında fərq qoymur.

Master-dən main-ə keçid

Tarixən Git-də defolt filial master adlanırdı. 2020-ci ilin iyununda Black Lives Matter hərəkatı IT sənayesində master və slave terminlərinə diqqət çəkdi. GitHub defolt filial üçün main termininə keçid elan etdi.

Oktyabr 2020-dən etibarən GitHub-da bütün yeni repozitoriyalar main filialı ilə yaradılır. GitLab və Bitbucket də main-i defolt ad kimi dəstəkləməyə başladı. Git 2.28 (iyul 2020) defolt filial adını konfiqurasiya etmək üçün init.defaultBranch seçimini əlavə etdi.

Texniki olaraq mövcud filialın adını master-dən main-ə dəyişmək sadə əməliyyatdır. Əsas çətinlik CI/CD konfiqurasiyalarında, sənədlərdə və tərtibatçıların lokal repozitoriyalarında bütün istinadları yeniləməkdir.

Mövcud repozitoriyada filialın adını dəyişmək üçün yerinə yetirin:

# Master-in main-ə lokal olaraq adlandırılması
git branch -m master main

# Uzaq repozitoriyanın yenilənməsi
git push -u origin main

# Serverdə köhnə master-in silinməsi
git push origin --delete master

# Serverdə HEAD-in yenilənməsi
# (GitHub veb interfeysi vasitəsilə: Settings → Branches → Default branch)

Main-in Git Flow və GitHub Flow-da rolu

Git Flow və GitHub Flow main filialının rolunu fərqli müəyyənləşdirir. Model seçimi komandanın ölçüsündən, buraxılış tezliyindən və kod sabitliyi tələblərindən asılıdır.

Mobil tətbiq inkişafı üçün standart Git Flow-dur, çünki App Store və Google Play-də tətbiq dərc etmək sabit buraxılış dövrlərinə malikdir. GitHub Flow gündə bir neçə dəfə yerləşdirmə imkanı olan veb layihələr üçün daha uyğundur.

GitHub Flow — sadələşdirilmiş yanaşma

GitHub Flow-da develop filialı yoxdur. Bütün feature filialları birbaşa main-dən yaradılır və tamamlandıqdan sonra Pull Request vasitəsilə geri birləşdirilir. Main-ə hər birləşmə avtomatik olaraq istehsala yerləşdirməni işə salır. Bu model yüksək test avtomatlaşdırması və komanda intizamı tələb edir.

GitHub Flow-da develop filialı yoxdur. Bütün feature filialları birbaşa main-dən yaradılır və tamamlandıqdan sonra Pull Request vasitəsilə geri birləşdirilir. Main-ə hər birləşmə avtomatik olaraq istehsala yerləşdirməni işə salır. Bu model yüksək test avtomatlaşdırması və komanda intizamı tələb edir.

Main filialının qorunması

Branch protection main üçün — istənilən kommersiya layihəsində məcburi qurğudur. Olmadan təsadüfi push yarımçıq kodu istehsala göndərə və ya bütün istifadəçilər üçün işləyən tətbiqi sındıra bilər.

• Require pull request — main-ə birbaşa push qadağandır. Bütün dəyişikliklər PR vasitəsilə, baxışla.
• Require approvals — main-ə birləşmə üçün minimum 2 təsdiq (bir rəyçinin səhvi halında).
• Require status checks — birləşmədən əvvəl bütün CI/CD yoxlamaları uğurlu olmalıdır.
• Require up-to-date — PR main-in ən son commit-inə əsaslanmalıdır.
• Include administrators — qoruma hətta depo sahiblərinə də şamil edilir.
• Require signed commits — main-dəki bütün commit-lər GPG açarı ilə imzalanmalıdır.

Bütün altı qaydanın konfiqurasiyası — 10 000+ istifadəçi auditoriyası olan mobil layihələr üçün standartdır. Kiçik layihələr üçün ilk üç qayda kifayətdir.

Müxtəlif layihə növləri üçün qoruma səviyyələrinin müqayisəsi

Main-in qoruma səviyyəsi layihənin miqyasından asılıdır. Startup minimal qoruma ilə keçinə bilər, enterprise tətbiq isə maksimum məhdudiyyətlər tələb edir.

Main-də buraxılışlar və teqlər

Teqləmə (tagging) — main-də konkret commit-lərə adlandırılmış istinadlar yaratmaq təcrübəsidir. Hər bir teq istehsala buraxılmış tətbiq versiyasına uyğundur. Bu, debug və ya patch üçün istənilən əvvəlki buraxılışa sürətli keçid imkanı verir.

Mobil tətbiq inkişafında teq adlandırma standartı — SemVer (Semantic Versioning): v1.2.3, burada birinci nömrə əsas versiya (breaking changes), ikinci — kiçik (yeni funksiyalar), üçüncü — patch (düzəlişlər).

Teq release filialının main-ə birləşməsindən sonra yaradılır. Bu commit daha sonra CI/CD-də yığılır, imzalanır və tətbiq mağazasına göndərilir. Teqdə xəta aşkar edilərsə, həmin teqdən hotfix filialı yaradılır.

# Annotasiya edilmiş buraxılış teqinin yaradılması
git tag -a v2.4.1 -m "Release version 2.4.1"

# Teqin serverə göndərilməsi
git push origin v2.4.1

# Repozitoriyadakı bütün teqlərə baxış
git tag -l "v2.*"

# Konkret teqdən hotfix filialının yaradılması
git checkout -b hotfix/crash-fix v2.4.1

Git Flow filial iyerarxiyası

Git Flow-da filial iyerarxiyasını başa düşmək birgə inkişafın düzgün təşkili üçün əsasdır. Hər bir filial növü öz mənbəyinə, təyinatına və birləşmə qaydalarına malikdir.

• Main (1-ci səviyyə) — kök filial, yalnız buraxılış versiyalarını ehtiva edir. Deponun inisiallaşdırılması zamanı yaradılır.
• Develop (2-ci səviyyə) — layihənin başlanğıcında main-dən yaradılır. Bütün funksiyaların inteqrasiya kodunu ehtiva edir.
• Feature (3-cü səviyyə) — develop-dən yaradılır. Ayrı-ayrı funksiyaların izolyasiya olunmuş inkişafı.
• Release (2-ci səviyyə) — develop-dən yaradılır. Müəyyən buraxılışın çıxarılması üçün hazırlıq.
• Hotfix (2-ci səviyyə) — main-dən yaradılır. İstehsalın kritik səhvlərinin təcili düzəldilməsi.

Vacib qayda: feature heç vaxt birbaşa main-ə birləşdirilmir. feature → develop → release → main — düzgün birləşmə zənciridir. Bu qaydanın pozulması bütün Git Flow modelini mənasız edir.

Main ilə iş üçün əmr nümunələri

Ssenarini nəzərdən keçirək: komanda v2.5.0 buraxılışının hazırlığını tamamladı. Release filialı yoxlanıldı və main-ə birləşməyə hazırdır. Birləşmədən sonra teq yaradılır və buraxılış dərc olunur.

# Main-ə keçid və yeniləmə
git checkout main
git pull origin main

# Yoxlanılmış release filialının birləşdirilməsi
git merge --no-ff release/2.5.0

# Buraxılış teqinin yaradılması
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Main və teqin serverə göndərilməsi
git push origin main --tags

--no-ff (no fast-forward) bayrağı, birləşmə göstəricinin sadə yerdəyişməsi ilə yerinə yetirilə bilsə belə, birləşmə commit-inin yaradılmasını təmin edir. Bu, dəyişikliklərin release filialından gəldiyi barədə məlumatı qoruyur və tarixin təhlilini asanlaşdırır.

Main vasitəsilə hotfix ilə iş

İstehsalda kritik xəta aşkar edilərsə, proses adi buraxılışdan fərqlənir. Hotfix main-dən yaradılır və düzəlişdən sonra həm main-ə, həm də develop-ə birləşdirilir.

İstehsalda kritik xəta aşkar edilərsə, proses adi buraxılışdan fərqlənir. Hotfix main-dən yaradılır və düzəlişdən sonra həm main-ə, həm də develop-ə birləşdirilir.

# Main-dən hotfix filialının yaradılması
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Düzəliş və commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfix-in main-ə geri birləşdirilməsi
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hotfix-in həmçinin develop-ə birləşdirilməsi
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix filialının silinməsi
git branch -d hotfix/2.5.1-crash-fix