Centralizied Strategy. | Mərkəzləşdirilmiş strategiya.
Adətən bu strategiya kiçik komanda da işlənir. Əgər komanda o qədər də güclü bilmirsə git sistemini, o zaman bu strategiyadan istifadə edərək daha tez tədbiqin developmentinə başlamaq olur. Əsas məntiq odur ki, bütün kommitlər bir başa origin/master budağına push edilir. Və tədbiqin üzərində işləyərkən budağlar yaradılmır. Üstünlüyü sadəlik olsa da, praktikada o qədər də keyfiyyətli nəticə olmur. Yuxarıda gördüyünüz şəkil nümünə kimi sxemi çəkilib.
Feature-branch workflow | Funksionallıq-budağ strategiyası
Feature-branch workflow danışacağımız növbəti strategiyadır. Bu strategiya da kiçik komanda ilə işləyərkən istifadə olunur, lakin daha effektivdir. Əsas məntiq odur ki, bütün funksionallığ budağların üzərində işlənir və sonra master budağına birləşdirilir. Yəni master budağında dəyişiklik yalnız budağlardan olur.
Gitflow strategy | Gitflou strategiyası
Gitflou strategiyası 2010cu ildə Norveçli developer tərəfindən yaradılıb və istifadə olunub. Mən bu strategiya haqqında qısaca yazıb, sizə məlumat verəcəm. Daha detallı oxumaq istəyənlər, developerin rəsmi bloqundan oxuya bilər. Developer qeyd edib ki, bu strategiya indi aktual olmaya bilər, lakin siz proyektinizin əvvəlki versiyalarını da dəstəkləyirsinizsə, sizə maraqlı ola bilər.
Keçək strategiyanın özünə. Əsas ideya budaqlara köklənir, lakin əvvəlcədən müəyyən edilmiş budaqlara. Yəni proyekt developer budağında yazılır, master budağında yalnız istifadəyə(productiona) veriləcək kod öz yerini tapır. Bütün funksionallıq üçün yaradılan budaqlar developer budağından ayrılır. Funksionallıq hazır olduqda onu developer budağına müəyyən şərt əsasında birləşdiririk. Müəyyən şərt o qədər də böyük bir şərt deyil. Sadəcə fast-forward merge elə edilməlidir ki, developer budağına birləşəndə yeni kommit yaradılsın. Beləliklə budağın olduğu haqda məlumat itmir. Yuxarıda şəkildə sağ tərəfdə misal qeyd olunub. Eyni məntiqlə bir neçə variantda istifadə edərək, bütün lazımı məqamları əhatə edəcək bir strategiya qurmaq olur. Misal kimi hotfix budağının əlavə olunmasını qeyd edirəm, amma istifadə etmək üçün developerin bloquna nəzər yetirə bilərsiz.
Gitflow strategiyası haqqında bu qədər. Vincent Driessenin bloqunu oxumağa dəyər daha detallı bilməkdən ötəri və ümumiyyətlə maraqlı kontent oxumaq üçün.
Integration Manager Workflow | Inteqrasiya İdarə Strategiyası
İntegration manager workflow strategiyası daha böyük komanda ilə işlədikdə istifadə olunur. Adətən komandanın sayı elə olur ki, hamısını bir araya toplayıb müzakirələr etmək olmur. Bu zaman developerlər arasında qruplaşmalar gedir. Strategiyanın ideyasını yuxarıda qeyd olunan sxemin üzərində müzakirə edək. Deməli əsas repository “blessed repository” olur. Blessed repositoriyə yalnız integration manager push, developerlər isə yalnız pull edə bilir. İntegration manager developer public repositoriyalarından pull edir ki, developerlərin elədiklərini özünə yükləyib, yoxlayıb, blessed repositoriyə push etsin. Beləliklə İntegration managerin rolu mütamadi olaraq “developer public”dən pull edib, blessed repositoriyə push etməkdir. Developerlər isə öz kodlarını yazıb developer public repositorilərinə hər dəfə push edirlər. Düşünürəm İntegration manager vorkflou haqqında bu qədər.
Dictator and Lieutenants workflow | Diktator və Leytenant strategiyası
Diktator və Leytenant strategiyası integration manager strategiyasına oxşayır. Sadəcə developerlərin sayı artdıqca, artıq Dictator Leytenant strategiyasına keçmək olar. Eyni qaydada burada da “Blessed repository” var, haradan pull etmək olur, lakin yalnız diktator push edə bilir. Diktator leytenantlardan pull edir, onların kodunu yoxlayır və blessed repositoriyə yükləyir. Leytenantlar da qismən integration manager elədiklərini edirlər, yeganə fərq odur ki, onlar blessed repositoriyə push edə bilmirlər.
Forking worklflow
Forking strategiyası elə Github tərəfindən istifadə olunur. Strategiya adətən open source proyektlərdə görünür. Burada müəllifin proyektini istənilən şəxs kopyalayıb, dəyişiklik edə bilər. Əlavə olaraq həvəskar developerlər, yeni funksionallıqlar üzərində çalışıb, proyektə əlavə edə bilər.
Bu strategiyada əsas olan original developerdir. O proyekti yaradır və onu public yerləşdirir. Lakin həmin proyektdə yalnız fork etmık imkanı saxlayır. Fork etmək proyekti kopyalayıb üzərinə istənilən dəyişikliyi etmək imkanıdır. Fork edib, üzərində dəyişikliy etdikdən sonra commitləri əsas proyektə yükləmək üçün pull request yaradılır və original developerə göndərir ki, o dəyişikliklərə baxıb, yoxlayıb əsas repozitoriyaya yükləyə bilsin.
Strategiyalar haqqında bu qədər. Diqqətiniz üçün çox sağ olun.
Youtube: https://www.youtube.com/c/AyTiQaqa%C5%9F
Facebook Qrup: https://www.facebook.com/groups/aytiqaqash
Facebook Səhifə: https://www.facebook.com/aytiqaqash
Telegram Qrup: https://t.me/aytiqaqashlar
Telegram Kanal: https://t.me/aytiqaqash
İnstagram: https://www.instagram.com/aytiqaqash/
Twitter: https://twitter.com/aytiqaqash