7.11 Git Alətləri - Alt Modullar

Uzaqdan Layihədə submodulları istifadə etməyin ən sadə modeli, sadəcə bir layihə istifadə etməyiniz və zaman zaman yeniləmələri almaq istəməyiniz, ancaq həqiqətən yoxlanışda bir şey dəyişdirməməyinizdir. Oradakı sadə bir nümunəyə baxaq.

Bir submodulda yeni işin olub olmadığını yoxlamaq istəyirsinizsə, qovluğa girib local kodu yeniləmək üçün yuxarıdakı branch-ı git fetch və git merge işlədə bilərsiniz.

İndi əsas layihəyə qayıdırsınız və git diff --submodule işlədirsinizsə, submodulun yeniləndiyini və ona əlavə olunanların siyahısını əldə etdiyini görə bilərsən. Hər dəfə git diff işlədikdə --submodule yazmaq istəmirsinizsə, onu diff.submodule konfiqurasiya dəyərini “log”-a təyin edərək standart format kimi təyin edə bilərsiniz.

Bu anda commit etsəniz, submodulu digər insanlar yenilədikdə yeni kodun içərisinə bağlayacaqsınız.

Submodulda manual olaraq fetch edilib birləşməməyi istəsəniz, bunu etmək üçün daha asan bir yol var. git submodule update --remote işlədirsinizsə, Git submodullara daxil olacaq və sizin üçün yeniləyəcəkdir.

Bu əmr standart olaraq, submodul deposunun master branch-na çıxışı yeniləmək istədiyinizi qəbul edəcəkdir. İstəsəniz, bunu fərqli bir şeyə təyin edə bilərsiniz. Məsələn, DbConnector submodulunun o deponun “stable” branch-nı izləməyini istəyirsinizsə, onu ya .gitmodules sənədinizdə (beləcə hər kəs onu izləyər) və ya local .git/config faylında quraşdıra bilərsiniz. Gəlin onu .gitmodules sənədinə qoyaq:

Əgər -f .gitmodules deaktiv etsəniz, bu yalnız sizin üçün dəyişikliyə səbəb olacaq, ancaq hər kəsin də olduğu kimi bu məlumatı depo ilə izləməyi daha mənalı olar.

Bu nöqtədə git status işlədikdə, Git submodulda “new commits” olduğunu göstərəcəkdir.

Konfiqurasiya parametrini status.submodulesummary təyin etsəniz, Git sizə submodullarındakı dəyişikliklərin qısa xülasəsini də göstərəcəkdir:

Bu nöqtədə git diff işlədirsinizsə, həm də .gitmodules faylımızı dəyişdirdiyimizi, həmçinin endirdiyimiz və submodul layihəmizin yerinə yetirməyə hazır olduğumuz bir sıra işlərin olduğunu görə bilərik.

Bu, olduqca əlverişlidir, çünki həqiqətən submodulumuzda verəcəyimiz commit-lərin qeydini görə bilərik. Commit etdikdən sonra bu məlumatı git log -p işlədərkən də görə bilərsiniz.

Git standart olaraq git submodule update --remote-u işlətdiyiniz zaman submodullarınızın hamısını yeniləməyə çalışacaqdır. Əgər bunların çoxu varsa, yeniləməyə çalışmaq istədiyiniz yalnız submodulun adını ötürmək istəyə bilərsiniz.

İndi MainProject depolarının öz local klonuna sahib olan işçinizin yerinə keçək. Yeni düzəlişlərinizi əldə etmək üçün sadəcə git pull yerinə yetirmək kifayət etmir:

Varsayılan olaraq, git pull əmri yuxarıda göstərilən ilk əmrin nəticələrində gördüyümüz kimi, submodulları rekursiv şəkildə dəyişir. Ancaq submodulları yeniləməz. Bu, submodulun “modified” olduğunu və “new commits” verdiyini göstərən git status əmrinin çıxışı ilə göstərilir. Üstəlik, yeni commit nöqtəsini göstərən mötərizələr (<), bu tapşırıqların MainProject-də qeydə alındığını, lakin local DbConnector yoxlanışında olmadığını göstərir. Yeniləməni yekunlaşdırmaq üçün git submodule update işləməlisiniz:

Etibarlı tərəfdə olmaq üçün MainProject yeni submodulları əlavə etməyi commit etdiyi submodullar varsa, --init və --recursive flag-larından istifadə edərək git submodule update-ni işə salmalısınız.

Bu prosesi avtomatlaşdırmaq istəyirsinizsə,  --recurse-submodules flag-nı git pull əmrinə əlavə edə bilərsiniz (Git 2.14-dən bəri). Bu, Git pull etməkdən dərhal sonra git submodule update-ni işə salacaq və submodulları düzgün vəziyyətə gətirəcəkdir. Üstəlik, Git’i həmişə --recurse-submodules ilə pull etmək istəsəniz, submodule.recurse konfiqurasiya seçimini "true" olaraq təyin edə bilərsiniz (Git 2.15-dən bəri git pull üçün işləyir). Bu seçim Git-in onu dəstəkləyən bütün əmrlər üçün --recurse-submodules flag-ından istifadə etməsini təmin edəcəkdir (clone xaricində).

Super layihə yeniləmələrini pulling edərkən baş verə biləcək xüsusi bir vəziyyət var: ola bilər ki, yuxarıdakı depo, pull etdiyiniz commit-lərin birində .gitmodules faylındakı submodulun URL-sini dəyiştirmiş ola bilər. Bu, məsələn submodul layihəsi hosting platformasını dəyişdirərsə, baş verə bilər. Bu vəziyyətdə, super layihə deposunda local olaraq tənzimlənmiş submodulun uzaq yerində tapılmayan bir submodul əməlinə istinad edərsə, git pull --recurse-submodules və ya git submodule update üçün uğursuz ola bilər. Bu vəziyyəti düzəltmək üçün git submodule sync əmri tələb olunur:

Çox güman ki, submodullardan istifadə edirsinizsə, bunu əsas layihədə (və ya bir neçə submodulda) kod üzərində işləyərkən eyni zamanda submoduldakı kod üzərində işləmək istədiyiniz üçün edirsiniz. Əks təqdirdə bunun əvəzinə daha sadə bir asılılıq idarəetmə sistemindən istifadə edərdiniz (məsələn Maven və ya Rubygems).

Beləliklə, indi əsas layihə ilə eyni vaxtda submodulda dəyişiklik etmək və eyni zamanda bu dəyişiklikləri commit etmək və yayımlamaq nümunəsinə baxaq.

İndiyə qədər, submodul depolarından dəyişiklik almaq üçün git submodule update əmrini işlətdikdə Git dəyişiklikləri əldə edib subdirectory-da faylları yeniləyəcək, lakin sub-repository-i “detached HEAD” vəziyyəti adlanacaq. Bu o deməkdir ki, dəyişiklikləri izləyən local (məsələn, master kimi) branch yoxdur. Heç bir işləyən branch izləmə dəyişiklikləri olmadan o deməkdir ki, submodula dəyişiklik etsəniz də, növbəti dəfə git submodule update işlədikdə bu dəyişikliklər tamamilə itiriləcəkdir. Bir submoduldakı dəyişikliklərin izlənməsini istəyirsinizsə, əlavə addımlar atmalısınız.

Giriş və hack etmək daha asan olması üçün alt modulunuzu qurmaq üçün iki şey etməlisiniz. Hər bir submodula daxil olmalı və işləmək üçün bir branch-ı yoxlamalısınız. Sonra dəyişikliklər etdikdən sonra Git’ə nə etməli olduğunu izah etməlisiniz və sonra git submodule update --remote yuxarıdan yeni işə pull ediləcəkdir. Seçimlər bunlardır ki, onları local işinizə birləşdirə bilərsiniz və ya local işinizi yeni dəyişikliklərin başına qaytarmağa cəhd edə bilərsiniz.

Əvvəlcə submodul qovluğumuza daxil olub, bir branch-ı yoxlayaq.

Submodulumuzu “merge” seçimi ilə yeniləməyə çalışaq. Manual müəyyənləşdirmək üçün update çağırışımıza --merge seçimini əlavə edə bilərik. Burada bu submodul üçün serverdə bir dəyişiklik olduğunu və birləşdirildiyini görərik.

DbConnector qovluğuna daxil olsaq, dəyişikliklər local stable branch-da göstərilmişdir. İndi gəlin görək kitabxanaya öz local dəyişikliklərimizi edərik və başqası eyni zamanda başqa bir dəyişikliyi yuxarıya push edəndə nə olacağına baxaq.

İndi submodulumuzu yeniləsək, local bir dəyişiklik etdikdə və yuxarıda əlavə etməli olduğumuz bir dəyişikliyə sahib olduğumuzu görə bilərik.

--rebase və ya --merge unudarsanız, Git yalnız submodulu serverdəki hər hansı bir şeyə yeniləyəcək və layihənizi ayrı bir HEAD vəziyyətinə qaytaracaqdır.

Əgər bu baş verərsə, narahat olmayın, sadəcə qovluğuna qayıda bilər və yenidən branch-nızı yoxlaya bilərsiniz (bu hələ də işinizi özündə saxlayacaq) origin/stable (və ya istədiyiniz hər hansı bir branch-ı) manual olaraq birləşdirə və ya dəyişdirə bilərsiniz.

Submoduldakı dəyişikliklərinizi etməmisinizsə və problem yarada biləcək bir submodul yeniləməsini işlədirsinizsə, Git dəyişiklikləri alır, ancaq submodul qovluğunuzda qeyd olunmamış işləri yazmır.

Yuxarıda dəyişdirilmiş bir şey ilə ziddiyyətli dəyişikliklər etmisinizsə, Git yeniləməni işlədiyiniz zaman sizə xəbər verəcəkdir.

Submodul qovluğuna girib konflikti normal qaydada istədiyiniz kimi düzəldə bilərsiniz.

İndi submodul qovluğunda bəzi dəyişikliklər var. Bunlardan bəziləri yeniləmələrimiz tərəfindən yuxarıdan gətirilib, digərləri local olaraq hazırlanıb və hələ də onları açmamışıq.

Əsas layihədə iştirak etsək və submodula dəyişikliklərini də pushing etmədən push etsək, dəyişikliklərimizi yoxlamağa çalışan digər insanlara problemə yarnacaq, çünki asılı olan submodul dəyişikliklərini əldə etmək üçün bir yol qalmayacaqlar. Bu dəyişikliklər yalnız local nüsxəmizdə olacaq.

Bunun baş verməməsinə əmin olmaq üçün Git-dən əsas layihəni push etmədən əvvəl bütün submodullarınızın düzgün şəkildə push edildiyini yoxlamağı xahiş edə bilərsiniz. git push əmri, “check” və ya “on-demand” olaraq təyin edilə bilən --recurse-submodules argumentini alır. “check” seçimi, submodul dəyişikliklərindən hər hansı birinə push edilmədiyi təqdirdə, push etməyi asanlaşdıracaq.

Gördüyünüz kimi, bundan sonra da nə etmək istədiyimiz barədə bəzi faydalı məsləhətlər verir. Sadə seçim odur ki, hər bir submodula daxil olub uzaqdan mövcud olduqlarına əmin olmaq üçün manual olaraq uzaqdan idarə etməkdir və sonra bu push etməyi yenidən sınamaqdır. Bütün push etməklər üçün yoxlama davranışının olmasını istəyirsinizsə,git config push.recurseSubmodules check əməliyyatı edərək bu davranışı standart hala gətirə bilərsiniz.

Digər seçim, “on-demand” dəyərini istifadə etməkdir, bu sizin üçün bunu etməyə çalışacaqdır.

Gördüyünüz kimi, Git DbConnector moduluna girdi və əsas layihəyə keçməmişdən əvvəl push etdi. Bu submodul push etmək nədənsə uğursuz olarsa, əsas layihə push etmə də uğursuz olacaq. Bu davranışı standart olaraq git config push.recurseSubmodules on-demand edərək edə bilərsiniz.

Bir submodul arayışını başqası ilə eyni vaxtda dəyişdirsəniz, bəzi problemlərlə qarşılaşa bilərsiniz. Yəni, submodul tarixləri bir-birindən ayrılıbsa və bir super layihədə branch-ları ayırmaq öhdəliyindədirsə, düzəltmək üçün bir az iş tələb oluna bilər.

Təqdim olunanlardan biri digərinin birbaşa əcdadıdırsa (sürətli birləşmə), onda Git birləşmə üçün sadəcə sonuncunu seçəcəkdir ki, beləcə yaxşı işləyəcək.

Git sizin üçün mənasız birləşməyə belə cəhd etməyəcək. Submodul bir-birindən fərqli commit edirsə və birləşdirilməlidirsə, buna bənzər bir şey alacaqsınız:

Beləliklə, əsasən burada nə baş verən budur ki, Git iki branch-ın submodulun tarixində bir-birindən fərqli olan və birləşdirilməli olduğunu nöqtələri qeyd etdi. Bunu çaşdırıcı olan “merge following commits not found” kimi izah edir, amma bunun niyə olduğunu birazdan izah edəcəyik.

Problemi həll etmək üçün submodulun hansı vəziyyətdə olduğunu müəyyənləşdirməlisiniz. Qəribədir ki, Git buraya kömək etmək üçün çox məlumat vermir, hətta tarixin hər iki tərəfinin verdiyi SHA-1-lərdən də məlumat vermir. Xoşbəxtlikdən, bunu anlamaq çox sadədir. git diff işlədirsinizsə, birləşdirməyə çalışdığınız hər iki branch-da qeyd olunan əmsalların SHA-1-lərini əldə edə bilərsiniz.

Beləliklə, bu vəziyyətdə, eb41d76 submodulumuzda biz sahip olduğumuz commit və c771610 upstream-in sahib olduğu commitdir. Submodule qovluğumuza daxil olsaq, birləşmə ona toxunmayacağı üçün artıq eb41d76 üzərində olmalıdır. Hansı səbəbdən olursa olsun, sadəcə ona işarə edən bir branch yarada və nəzarət edə bilərsiniz.

Önəmli olan qarşı tərəfin commit-nin SHA-1 olmasıdır. Bu birləşdirib və həll etmək məcburiyyətində olduğunuz bir şeydir. Sadəcə birbaşa SHA-1 ilə birləşməyə cəhd edə bilərsiniz və ya bunun üçün bir branch yarada və sonra birləşməyə cəhd edə bilərsiniz. Sonuncunu, daha yaxşı birləşmə commiti verəcəyi üçün tövsiyə edirik.

Beləliklə, submodul qovluğumuza daxil olacağıq, git diff-dən ikinci SHA-1 əsasında “try-merge” adlı bir branch yaradacağıq və manual olaraq birləşdirəcəyik.

Burada faktiki olaraq birləşmə konflikti var, buna görə də bu problemi həll etsək və öhdəsinə götürsək, əsas layihəni nəticə ilə yeniləyə bilərik.

Bir az qarışıq ola bilər, amma həqiqətən çox çətin deyil.

Maraqlıdır ki, Git-in ələ keçirdiyi başqa bir hadisə də var. Birləşdirmə əməliyyatı tarixində hər ikisini ehtiva edən submodule qovluğunda varsa, Git bunu sizə mümkün bir həll yolu kimi təklif edəcəkdir. Submodule layihəsinin bir nöqtəsində kimsə bu iki əmrdən ibarət branch-ları birləşdirdiyini görür, bəlkə buna görə bunlardan birini istəyərsən.

Buna görə əvvəllər edilən xəta mesajı “merge following commits not found” idi, çünki bunu edə bilmədi. Çaşdırıcıdır, çünki bunu etmək üçün kimin cəhd etməsini gözləyəcək ki?

Bir məqbul birləşmə commiti taparsa, bu kimi bir şey görəcəksiniz:

Git-in təklif etdiyi əmr indeksin yenilənməsini təmin edir, sanki git add (münaqişəni təmizləyən) kimi işlədin, sonra commit edin. Yəqin ki, bunu etməməlisiniz. Asanlıqla submodul qovluğuna girib fərqin nə olduğunu görə bilərsiniz, bu tapşırığa sürətlə irəliləyin, düzgün sınaqdan keçirin və sonra commit edin.

Bu eyni şeyi yerinə yetirir, amma heç olmasa bu şəkildə bunun işlədiyini və tamamlandığınızda submodul qovluğunda kodunuz olduğunu yoxlaya bilərsiniz.

Hər submodulda bəzi ixtiyari əmrləri işlətmək üçün foreach submodul əmr var. Eyni layihədə bir neçə submodul varsa, bu həqiqətən faydalı ola bilər.

Məsələn, deyək ki, yeni bir xüsusiyyətə başlamaq və ya səhv düzəltmək istəyirik və bir neçə submodulda işimiz var. Bütün işləri bütün submodullarımızda asanlıqla yığa bilərik.

Sonra yeni bir branch yarada və bütün alt modullarımızda ona keçə bilərik.

Fikir aldın. Həqiqətən edə biləcəyiniz bir şey, əsas layihənizdə və bütün alt layihələrinizdə dəyişdirilənlərdən gözəl birləşmiş fərq yaratmaqdır.

Burada submodulda bir funksiya təyin etdiyimizi və əsas layihədə adlandırdığımızı görə bilərik. Bu açıqca sadələşdirilmiş bir nümunədir, amma ümid edirik bunun necə faydalı ola biləcəyi barədə sizə bir fikir verəcək.

Bu əmrlərdən bəziləri üçün bəzi alias-lar qurmaq istəyə bilərsiniz, çünki onlar kifayət qədər uzun ola bilər və əksəriyyətini defolt halına gətirmək üçün konfiqurasiya seçimlərini təyin edə bilməzsiniz. Git ləqəblərinin qurulmasını Git Alias’lar -də qbaa bilərsiniz, ancaq Git-də submodullarla çox işləməyi planlaşdırırsınızsa, qurmaq istədiyiniz bir nümunəni burada tapa bilərsiniz.

Bu yolla submodullarıınızı yeniləmək istədikdə git supdate və ya submodula asılılığını yoxlamaqla basmaq üçün git spush işlədə bilərsiniz.

Məsələn, branch-larında submodulları olan branch-ları dəyişdirmək Git 2.13-dən daha köhnə Git versiyaları ilə də çətin ola bilər. Yeni bir branch yaradırsınızsa, orada bir submodul əlavə edin və sonra bu submodul olmadan yenidən bir branch-a keçin, submodul qovluğu hələ də yığılmamış bir qovluq olaraq qalır:

Qovluqda silmək çətin deyil, amma orada olması bir az çaşdırıcı ola bilər. Əgər onu çıxarıb sonra yenidən həmin submodulu olan branch-a qayıtsanız, onu təkrarlamaq üçün submodule update --init işlətməlisiniz.

Yenə də həqiqətən çox çətin deyil, ancaq bir az qarışıq ola bilər.

Yeni Git versiyaları (Git >= 2.13), keçid etdiyimiz branch üçün submodulları düzgün vəziyyətdə yerləşdirməyin qayğısına qalan git checkout əmrinə --recurse-submodules flagı əlavə etməklə bütün bunları asanlaşdırır.

git checkout-nın --recurse-submodules flag-dan istifadə, super layihədə bir neçə branch-da işləyərkən faydalı ola bilər. Həqiqətən, submodulunu fərqli commit-lərdə qeyd edən branch-lar arasında keçsəniz, git status yerinə yetirildikdə, alt modul ‘modified’' olaraq görünəcək və “new commits” göstəriləcədir. Bu, submodule vəziyyətinin branch-ları dəyişdirərkən bir qayda olaraq aparılmamasıdır.

Bu, həqiqətən çaşdırıcı ola bilər, buna görə də layihənizdə submodullar olduqda həmişə git checkout --recurse-submodules etmək yaxşı bir fikirdir. --recurse-submodules flag-ı olmayan köhnə Git versiyaları üçün, yoxlanışdan sonra submodulları düzgün vəziyyətə gətirmək üçün git submodule update --init --recursive istifadə edə bilərsiniz.

Xoşbəxtlikdən, Git (>= 2.14) konfiqurasiya seçimini submodule.recurse qoyaraq həmişə --recurse-submodules flag-ından istifadə etməyi söyləyə bilərsiniz: git config submodule.recurse true. Yuxarıda qeyd edildiyi kimi, bu da Git-in --recurse-submodules seçimi olan hər bir əmr üçün submodullara təkrarlanmasını təmin edəcəkdir (git clone xaricində).

Bir çox insanın işlətdiyi digər əsas xəbərdarlıq subdirectory-dən submodullara keçməkdir. Layihənizdəki faylları izləmisinizsə və onları submodula köçürmək istəyirsinizsə, diqqətli olmalısınız və ya Git sizə qəzəblənəcəkdir. Layihənizin alt alt bölməsində fayllarınız olduğunu düşünün və onu bir subdirectory-ə keçirmək istəyirsiniz. Əgər subdirectory-ni silib sonra submodule add işlədirsinizsə, Git sizə qışqırır:

Əvvəlcə CryptoLibrary qovluğunu çıxartmalısınız. Sonra submodulu əlavə edə bilərsiniz:

İndi bir branch-da etdiyinizi düşünün. Bu sənədlərin submodula deyil, həqiqi ağacda olduğu bir branch-a geri dönməyə çalışarsanız, bu səhvinizi alırsınız:

Onu checkout -f ilə dəyişdirməyə məcbur edə bilərsiniz, ancaq bu əmrlə yenidən yazıla biləcəyiniz üçün orada saxlanmamış dəyişikliklərin olmadığından ehtiyatlı olun.

Sonra geri dönəndə nədənsə boş bir CryptoLibrary qovluğu alırsınız və git submodule update onu da düzəldə bilməz. Bütün sənədlərinizi geri qaytarmaq üçün submodul qovluğuna daxil olmalı və git checkout . başlatmalısınız. Bunu bir neçə submodul üçün işlətmək üçün submodule foreach skriptində işlədə bilərsiniz.

Qeyd etmək vacibdir ki, submodullar bu gün bütün Git məlumatlarını ən yaxşı layihənin .git qovluğunda saxlayırlar, buna görə Git-in çox köhnə versiyasından fərqli olaraq, submodule qovluğunu məhv etmək heç bir commiti və ya branch-nı itirməyəcəkdir.

Bu vasitələrlə submodullar eyni vaxtda bir neçə əlaqəli, lakin ayrıca layihələr üzərində inkişaf etdirmək üçün olduqca sadə və təsirli bir metod ola bilər.