Qarışıqlıq olmadan komanda işi: Git-də budaqlanma strategiyalarını anlamaq

Giriş

Git proqram təminatının yaradılmasında versiyaya nəzarət üçün faktiki sənaye standartına çevrildi. Git-in nə olduğunu və necə başlamaq lazım olduğunu öyrənmək üçün əvvəlcə bu barədə məqaləmi oxuyun. Oxumusan? Əla, davam edək! İstər-istəməz, Linus Towaldsın yaratdığı alət təqaüdə çıxmayacaq. Buna görə də, paylanmış komandaların git-də necə işlədiyi və bunun üçün hansı budaqlanma strategiyasının seçiləcəyi barədə danışmaq məntiqlidir. Və bu heç də boş sual deyil. Çox vaxt, bir-biri ilə əməkdaşlıq etməyən yeni tərtibatçılar komandasının yığıldığı bir vəziyyətdə, budaqlanma strategiyası qərar verilməli olan ilk şeylərdən biridir. Və bir strategiyanın digərindən daha yaxşı olduğunu sübut etmək üçün ağızdan köpüklənən insanlar olacaq. Ona görə də mən sizə onların ümumiyyətlə nə olduğu haqqında məlumat çatdırmaq istəyirəm.

Budaqlanma strategiyalarına ehtiyac varmı?

Ancaq bunlar lazımdır və hələ də lazımdır. Çünki komandada bir şeylə razılaşmırsınızsa, məlum olur ki, hər kəs istədiyini edəcək:

• istədiyi filialda işləmək;
• istədiyi digər filiallara birləşmək;
• bəzi filialları silin;
• yenilərini yaratmaq;
• və s - komanda üzvlərinin hər biri nəzarətsiz bir axın içindədir.

Beləliklə, aşağıda üç strategiya var. Get!

GitHub Flow strategiyası

Budaqlanma strategiyası, nə qədər qəribə olsa da, GitHub-da üstünlük təşkil edir :) Ona əməl edilməli olan bir sıra qaydalar əlavə olunur:

1. Əsas filialdakı kod pozulmamış və istənilən vaxt yerləşdirilməyə hazır olmalıdır (yəni, layihənin qurulmasına və serverdə yerləşdirilməsinə mane olacaq kodu ora yerləşdirə bilməzsiniz).
2. Yeni funksionallıq üzərində işləməyi planlaşdırdığınız zaman master budaq əsasında yeni filial (xüsusiyyət budağı) yaratmalı və ona mənalı bir ad verməlisiniz. Kodunuzu yerli olaraq təhvil verin və dəyişikliklərinizi müntəzəm olaraq uzaq depoda eyni filiala köçürün.
3. İşin hazır olduğunu və əsas şöbəyə birləşdirilə biləcəyini açıq şəkildə hiss etdikdə (və ya əmin deyilsinizsə, lakin geribildirim almaq istəyirsinizsə) Pull-Request açın (pull-sorğunun nə olduğunu burada oxuya bilərsiniz). görülən iş).
4. Çəkmə sorğusunda yeni funksiya təsdiqləndikdən sonra o, əsas filiala birləşdirilə bilər.
5. Dəyişikliklər əsas filiala birləşdirildikdə, onlar dərhal serverə yerləşdirilməlidir.

GitHub Flow-a görə, məlum olur ki, yeni bir şey üzərində işləməyə başlamazdan əvvəl, istər düzəliş, istərsə də yeni funksiya, master əsasında yeni filial yaratmalı və ona uyğun ad verməlisən. Sonra, icra üzərində iş başlayır. Siz daim eyni adlı uzaq serverə öhdəliklər göndərməlisiniz. Hər şeyin hazır olduğunu başa düşdükdə, master filialında bir çəkmə sorğusu yaratmalısınız. Sonra ən azı bir və ya daha yaxşısı iki nəfər bu koda baxıb Təsdiq et klikləməlidir. Adətən, layihənin komanda rəhbəri və başqası ona baxmalıdır, sonra siz çəkmə sorğusunu tamamlaya bilərsiniz. GitHub Flow həmçinin bir layihədə Davamlı Çatdırılma (CD) idarə etməsi ilə tanınır . Çünki master filialda dəyişikliklər edildikdə, onlar dərhal serverə yerləşdirilməlidir.

GitFlow strategiyası

Əvvəlki strategiya (GitHub Flow) əslində çox mürəkkəb deyildi. Budaqların iki növü var: master və xüsusiyyət budaqları. Ancaq GitFlow daha ciddidir. Heç olmasa yuxarıdakı şəkildən bunu başa düşə bilərsiniz) Bəs bu strategiya necə işləyir? Ümumiyyətlə, GitFlow iki daimi filialdan və bir neçə növ müvəqqəti filialdan ibarətdir (GitHub Flow kontekstində əsas filial daimi, digərləri isə müvəqqətidir). Daimi filiallar:

• usta: heç kim bu budağa toxunmamalıdır / ora nəyisə itələməlidir. Bu strategiyada master istehsalda (yəni real serverdə) istifadə olunan ən son stabil versiyanı göstərir;
• inkişaf inkişafın qoludur. Potensial olaraq qeyri-sabit ola bilər.

İnkişaf üç köməkçi müvəqqəti filialdan istifadə etməklə həyata keçirilir :

1. Xüsusiyyət filialları - yeni funksionallığın inkişafı üçün.
2. Buraxılış filialları - layihənin yeni versiyasının buraxılışına hazırlaşmaq.
3. Düzəliş filialları real serverdə real istifadəçilər tərəfindən artıq aşkar edilmiş qüsurun sürətli həllidir.

Xüsusiyyət filialları

Xüsusiyyət filialları yeni funksionallıq üçün tərtibatçılar tərəfindən yaradılır. Onlar həmişə inkişaf şöbəsi əsasında yaradılmalıdır. Yeni funksionallıq üzərində işi tamamladıqdan sonra inkişaf şöbəsində çəkmə sorğusu yaratmalısınız. Aydındır ki, böyük komandalarda eyni anda birdən çox xüsusiyyət şöbəsi ola bilər. Bir daha GitFlow strategiyasının təsvirinin əvvəlindəki şəklə diqqət yetirin.

Filialları buraxın

İnkişaf bölməsində lazımi sayda yeni funksiyalar hazırlandıqda, məhsulun yeni versiyasını buraxmağa hazırlaşa bilərsiniz. Buraxılış şöbəsi bu işdə bizə kömək edəcəkdir. inkişaf filialı əsasında yaradılmışdır. Buraxılış filialı ilə işləyərkən bütün qüsurları tapmaq və düzəltmək lazımdır. Buraxılış filialını sabitləşdirmək üçün tələb olunan hər hansı yeni dəyişikliklər də inkişafa birləşdirilməlidir. Bu, filialı sabitləşdirmək və inkişaf etdirmək üçün edilir. Testçilər filialın yeni buraxılış üçün kifayət qədər sabit olduğunu söylədikdə, o, master filialına birləşdirilir. Sonra, bu öhdəliyə bir teq yaradılır (teq: bu barədə ətraflı burada oxuya bilərsiniz ), ona versiya nömrəsi verilir. Nümunə olaraq, strategiyanın əvvəlindəki şəklə baxa bilərsiniz. Beləliklə, Tag 1.0 sadəcə layihənin 1.0 versiyasını göstərən bir etiketdir. Və son şey filial düzəlişidir.

Düzəliş filialları

Düzəliş filialları həmçinin master-da yeni versiyanın buraxılması üçün nəzərdə tutulub. Yeganə fərq bu buraxılışın planlaşdırılmamasıdır. Qüsurların sərbəst buraxıldığı və istehsalda artıq aşkar edildiyi vəziyyətlər var. Məsələn, iOS: onlar yeni versiyanı buraxan kimi dərhal buraxıldıqdan sonra aşkar edilən qüsurlar üçün düzəlişlər olan bir dəstə yeniləmə əldə edirsiniz. Bu baxımdan, bu qüsuru tez bir zamanda aradan qaldırmaq və yeni versiyanı buraxmaq lazımdır. Şəkilimizdə bu, 1.0.1 versiyasına uyğundur. İdeya ondan ibarətdir ki, real serverdə qüsuru düzəltməli olduğunuz anlarda yeni funksionallıq üzərində iş dayanmaya bilər (dediyimiz kimi, “istehsalda”: yenə də ingilis dilində istehsal sözünün surəti). Düzəliş filialı əsas filialdan yaradılmalıdır, çünki o, istehsalda işləyən vəziyyəti təmsil edir. Qüsurun həlli hazır olan kimi ustaya birləşdirilir və yeni etiket yaradılır. Buraxılış filialı hazırlamaq kimi, düzəliş şöbəsi də həllini inkişaf şöbəsinə birləşdirməlidir.

Forking iş axını strategiyası

Forking Workflow strategiyasının bir hissəsi olaraq, inkişaf elə bir şəkildə həyata keçirilir ki, iki anbar var:

1. Bütün dəyişikliklərin birləşdiriləcəyi orijinal depo.
2. Çəngəl deposu (bu, orijinalda dəyişiklik etmək istəyən başqa bir tərtibatçının əlində olan orijinal deponun surətidir).

İndiyə qədər bir az qəribə səslənir, elə deyilmi? Artıq açıq mənbə inkişafı ilə qarşılaşmış şəxslər üçün bu yanaşma artıq tanışdır. Bu strategiya aşağıdakı üstünlüyü təmin edir: inkişaf orijinalda birgə inkişaf hüququ verilmədən çəngəl deposunda həyata keçirilə bilər. Əlbəttə ki, orijinal deponun sahibi təklif olunan dəyişiklikləri rədd etmək hüququna malikdir. Ya da razılaşın və onları öldürün. Bu həm orijinal repozitoriyanın sahibi, həm də hansısa məhsulun yaradılmasında iştirak etmək istəyən tərtibatçı üçün əlverişlidir. Məsələn, siz Linux nüvəsinə dəyişikliklər təklif edə bilərsiniz . Linus onların mənalı olduğuna qərar verərsə, dəyişikliklər əlavə olunacaq (!!!).

Forking iş axını nümunəsi

İstifadə etmək istədiyiniz bəzi kitabxana olduqda Forking Flow GitHub-da istifadə olunur. Tam istifadəyə mane olan bir qüsuru var. Deyək ki, siz problemi kifayət qədər araşdırmısınız və həllini bilirsiniz. The Forking Workflow strategiyasından istifadə edərək, orijinal kitabxana deposunda işləmək hüququ vermədən bu problemi həll edə bilərsiniz. Başlamaq üçün bir depo seçməlisiniz, məsələn, Spring Framework nüvəsi .Yuxarı sağ küncdə Fork düyməsini tapın və üzərinə klikləyin: Bu bir az vaxt aparacaq, bundan sonra bu orijinal deponun surəti sizin yaddaşınızda görünəcək. çəngəl olduğunu göstərəcək şəxsi hesab: Onda siz həmişəki kimi bu depo ilə işləyə, master filiala dəyişikliklər əlavə edə və hər şey hazır olduqdan sonra orijinal depoya Pull-Request yarada bilərsiniz. Bunu etmək üçün Yeni Çəkmə sorğusu düyməsini klikləyin :

Hansı strategiyanı seçmək

Git sizə müxtəlif proseslər və strategiyalardan istifadə etməklə işləməyə imkan verən çevik və güclü vasitədir. Ancaq seçim nə qədər böyükdürsə, indi hansı strategiyanın seçiləcəyinə qərar vermək bir o qədər çətindir. Aydındır ki, hər kəsə uyğun gələn bir cavab yoxdur. Hamısı vəziyyətdən asılıdır. Bununla belə, bu işdə kömək edə biləcək bir neçə tövsiyə var:

1. Əvvəlcə ən sadə strategiyanı seçmək daha yaxşıdır. Yalnız zəruri hallarda daha mürəkkəb strategiyalara keçin.
2. Mümkün qədər az növ inkişaf etdirici filialı olan strategiyaları nəzərdən keçirin.
3. Müxtəlif strategiyaların müsbət və mənfi tərəflərinə baxın və layihəyə uyğun olaraq düzgün olanı seçin.

Git-də budaqlanma strategiyası haqqında sizə demək istədiyim bütün bunlardır. Diqqətiniz üçün təşəkkürlər :) GitHub hesabıma abunə olun , mən tez-tez işlərimi orada işimdə istifadə etdiyim müxtəlif texnologiya və alətlərdə yerləşdirirəm

faydalı bağlantılar

• GitHub axını: Git və GitHub-dan istifadə etməyin ən yaxşı yolu
• GitHub-da sorğuları çəkin və ya başqasının layihəsinə necə dəyişiklik edə bilərəm
• GitHub: Pull-Requests haqqında
• Davamlı İnteqrasiya, Çatdırılma və Yerləşdirmə Fərqlidir
• Git əsasları: Teqlərlə işləmək
• Habr: Git üçün uğurlu budaqlanma modeli