Archived documentation version rendered and hosted by DevNetExpertTraining.com
Git
Chapters ▾ 2nd Edition

5.1 Paylanmış Git - Distribyutorluq İş Axınları

Artıq bütün developer’lərin kodlarını paylaşması üçün mərkəz nöqtəsi olaraq qurulmuş remote bir Git deposuna sahib olduğunuzdan və lokal iş axınındakı əsas Git əmrləri ilə tanış olduğunuza görə bəzi paylanmış iş axınlarından necə istifadə edəcəyinizə baxacaqsınız.

Bu fəsildə paylayıcı və inteqrasiyaedici olaraq paylanmış bir mühitdə Git ilə necə işləməli olduğunuzu görəcəksiniz. Yəni bir layihəyə uğurla kod əlavə etməyi və onu və layihə qoruyucusunu mümkün qədər asanlaşdırmağı və bir sıra developer’lərlə layihəni necə uğurla davam etdirməyi öyrənəcəksiniz.

Distribyutorluq İş Axınları

Centralized Version Control Systems (CVCS)'dən fərqli olaraq distribyutor xarakterli Git sizə developerlərin proyektlərdə əməkdaşlığı zamanı daha çevik olmağa imkan verir. Mərkəzləşdirilmiş sistemlərdə hər developer mərkəz nöqtə ilə az ya da çox eyni işləyir. Gitdə hər developer potensial olaraq düyün və mərkəz nöqtədir; hər bir developer həm digər depolara kod dəstəyi verə bilər, həm də başqalarının işləyə biləcəyi və dəstək verə biləcəyi public depo saxlaya bilər. Bu, sizin layihəniz və ya komandanız üçün çox sayda workflow imkanlarını təqdim edir, buna görə də bu rahatlıqdan istifadə edən bir neçə ümumi paradiqma əhatə edəcəyik. Hər dizaynın güclü və mümkün zəif tərəflərini keçəcəyik; bu halda istifadə etmək üçün tək birini seçə bilər və ya bir neçəsinin xüsusiyyətlərini qarışdırıb uyğunlaşdıra bilərsiniz.

Mərkəzləşdirilmiş İş Axınları

Mərkəzləşdirilmiş sistemlərdə sadəcə bir əməkdaşlıq modeli mövcuddur - mərkəzləşdirilmiş iş workflow. Bir mərkəzi nöqtə ya da depo, kodu qəbul edə bilir və o zaman hər kəs öz işini onunla sinxronizasiya edir. Bir sıra developerlər düyünlərdir, yəni o mərkəzin istehlakçılarıdırlar və mərkəzləşdirilmiş yer ilə sinxronizasiya edirlər.

Mərkəzləşdirilmiş İş Axınları
Figure 54. Mərkəzləşdirilmiş İş Axınları

Bu o deməkdir ki, iki developer mərkəzdən klonlanırsa və hər ikisi də dəyişiklik edirsə, dəyişikliklərini geri göndərən ilk tərtibatçı bunu heç bir problem olmadan edə bilər. İkinci developer dəyişiklikləri qeyd etməzdən əvvəl birincinin işində birləşməlidir ki, ilk developerin dəyişikliklərini təkrar yazmasın. Bu anlayış Git-də Subversion (və ya hər hansı CVCS) olduğu kimi doğrudur və bu model Git’də də əla işləyir.

Şirkətinizdə və ya komandanızda mərkəzləşdirilmiş bir workflow ilə onsuz da rahatsınızsa, Git ilə bu iş istifadəsini asanlıqla davam etdirə bilərsiniz. Sadəcə bir depo qurun və komandanızdakı hər kəsə push imkanı verin; bu zaman Git istifadəçilərin bir-birinin üstünə təkrar yazmasına imkan vermir.

Fərz edək ki, John və Jessica eyni anda işə başlayır. John dəyişiklikini bitirib serverə yükləyir. Sonra Jessica dəyişikliklərini yükləməyə çalışır, lakin server onları rədd edir. Ona sürətli olmayan irəli dəyişiklikləri etməyə çalışdığını və qoşulub birləşməyincə edə bilməyəcəyi deyildi. Bu workflow bir çox insanı cəlb edir, çünki o bir çoxunun tanıdığı və rahat olduğu bir paradiqmadır.

Bu həm də kiçik komandalarla məhdudlaşmır. Git-in branch modeli yüzlərlə developerin eyni vaxtda onlarla branch vasitəsilə bir proyekt üzərində uğurla çalışmasını mümkün edir.

İnteqrasiya-Menecer İş Axınları

Git birdən çox uzaq depolarınıza sahib olmağa imkan verdiyi üçün, hər bir developerin öz şəxsi depolarına yazmaq və hər kəsin girişlərini oxumaq üçün bir workflow əldə etməsi mümkündür. Bu ssenariyə tez-tez “official” layihəsini təmsil edən bir kanonik bir depo daxildir. O proyektə dəstək vermək üçün proyektin öz ictimai klonunu yaradırsınız və dəyişikliklərinizi ona istiqamətləndirirsiniz. Sonra dəyişikliklərinizi çəkmək üçün əsas layihənin qoruyucusuna sorğu göndərə bilərsiniz. Ardından saylayıcı, depo saxlayan yerinizi məsafədən əlavə edə bilər, dəyişikliklərinizi yerli olaraq sınayır, onları branch-lara birləşdirə və geri depolarına push edə bilər. Proses aşağıdakı kimi işləyir (İnteqrasiya-menecer İş Axınları-a bax):

  1. Layihə qoruyucusu public depolarına push edir.

  2. Bir dəstəkçi həmin deponu klonlayır və dəyişikliklər edir.

  3. Dəstəkçi öz public kopyasını daxil edir.

  4. Dəstəkçi, düzəlişlərin alınmasını xahiş edən bir e-poçt göndərir.

  5. Təminatçı dəstəkçinin depolarını uzaqdan əlavə edir və yerli olaraq birləşdirir.

  6. Təminatçı birləşmiş dəyişiklikləri əsas depoya daxil edir.

İnteqrasiya-menecer İş Axınları
Figure 55. İnteqrasiya-menecer İş Axınları

Bu GitHub və ya GitLab kimi hub əsaslı alətlər proyekti forking etmək və dəyişikliklərinizi hamının görə bilməsi üçün fork etmək asan olduğundan çox istifadə olunanlardandır. Bu yanaşmanın əsas üstünlüklərindən biri odur ki, siz işləməyə davam edərkən əsas depo təminatçısı hər an dəyişikliklərinizi daxil edə bilər.

İştirakçılar layihənin dəyişikliklərini daxil etməsini gözləməli deyil - yəni, hər tərəf öz sürətiylə işləyə bilər.

Diktator və Leytenantların İş Axınları

Bu, çoxsaylı depozit bir workflow variantıdır. O, ümumiyyətlə yüzlərlə tərəfdaş ilə birgə nəhəng layihələr tərəfindən istifadə olunur və onun məşhur nümunələrindən biri Linux kernelidir. Müxtəlif inteqrasiya menecerləri depoların müəyyən hissələrinə cavabdehdirlər; onlara leytenantlar deyilir. Bütün leytenantların xeyirxah diktator kimi tanınan bir inteqrasiya meneceri var. Xeyirxah diktator öz direktoriyalarından bütün əməkdaşların çəkməli olduğu bir istinad depolarına göndərir. Proses belə işləyir ( Xeyirxah diktator İş Axınları-a bax):

  1. Daimi tərtibatçılar mövzu branch-ları üzərində işləyir və işlərini master-in üstünə qoyurlar. master branch diktatorun göndərdiyi istinad anbarıdır.

  2. Leytenantlar, developerlərin mövzu şöbələrini öz master branch-larına birləşdirirlər.

  3. Diktator leytenantların master branch-larını diktatorun üst branch-na birləşdirir.

  4. Son olaraq, diktator o master bu branch-ı arayış depozitinə göndərir ki, digər tərtibatçılar bunun üzərində yenidən yaza bilsinlər.

Xeyirxah diktator İş Axınları
Figure 56. Xeyirxah diktator İş Axınları

Bu cür woekflow çox da işlək deyil, lakin çox böyük layihələrdə və ya yüksək iyerarxik mühitlərdə faydalı ola bilər. Bu layihə rəhbərinə (diktatora) işin çox hissəsini həvalə etməyə və onları birləşdirmədən əvvəl çox nöqtədə böyük kod toplamağa imkan verir.

Mənbə Kodu Branch’larının İdarə Nümunələri

Note

Martin Fowler "Mənbə kodu filiallarını idarə etmək üçün nümunələr" kitabçası hazırlamışdır. Bu təlimat bütün ümumi Git workflowlarını əhatə edir və onlardan necə istifadə edəcəyinizi izah edir. Orada həmçinin yüksək və aşağı inteqrasiya tezliklərini müqayisə edən bir bölmə də var.

İş Axınlarının Qısa Məzmunu

Bəzi Git kimi paylanmış bir sistemlə mümkün olan bir çox istifadə olunan workflowlar vardır, ancaq bir çox dəyişikliyin xüsusi real dünya workflowunuza uyğun olmasının mümkün olduğunu görə bilərsiniz. İndi (ümid edirik ki) hansı iş axını birləşməsinin sizin üçün işləyə biləcəyini müəyyənləşdirə bildiyiniz üçün, müxtəlif axınları təşkil edən əsas rolları necə yerinə yetirəcəyinizə dair daha bir neçə misal göstərəcəyik. Növbəti hissədə bir layihəyə dəstək vermək üçün bir neçə ümumi nümunə haqqında məlumat əldə edəcəksiniz.

scroll-to-top