10.7 Git’in Daxili İşləri - Maintenance və Məlumatların Bərpası

Bəzən, Git avtomatik olaraq “auto gc” adlı bir əmr işlədir. Çox vaxt bu əmr heç bir şey etmir. Bununla birlikdə, bir çox boş obyekt (packfile-da olmayan obyektlər) və ya çox çox paket varsa, Git tam hüquqlu bir git gc əmrini işə salır. “gc” zibil yığmaq deməkdir və bu əmr bir sıra şeyləri yerinə yetirir: bütün boş obyektləri toplayır və onları paketlərə yerləşdirir, paketləri bir böyük paketə birləşdirir hər hansı bir commit-dən əlçatmaz olan və bir neçə aylıq olan obyektləri silir.

Avtomatik gc-ni aşağıdakı kimi manual olaraq işə sala bilərsiniz:

Yenə də bu tam olaraq heç bir şey etmir. Git-in həqiqi bir gc əmrini işə salması üçün təxminən 7,000 boş obyekt və ya 50-dən çox paketiniz olmalıdır. Bu məhdudiyyətləri sırasıyla gc.auto və` gc.autopacklimit` konfiqurasiya parametrləri ilə dəyişdirə bilərsiniz.

gc-nin edəcəyi başqa bir şey, istinadlarınızı bir fayla yığmaqdır. Tutaq ki, deponuzda aşağıdakı branch-lar və etiketlər var:

Əgər siz git gc işlədirsinizsə, artıq bu fayllar refs qovluğunda mövcud olmayacaq. Git bunları effektivlik naminə belə görünən .git/packed-refs adlı bir fayla köçürəcəkdir:

Bir istinadı yeniləsəniz, Git bu faylı redaktə etmir, əksinə refs/heads üçün yeni bir fayl yazır. Müəyyən bir istinad üçün uyğun SHA-1 əldə etmək üçün Git, refs qovluğunda həmin istinadı yoxlayır və sonra packed-refs faylını geri yük kimi yoxlayır. Beləliklə, refs qovluğunda bir müraciət tapa bilmirsinizsə, ehtimal ki,packed-refs faylınızdadır.

Faylın ^ ilə başlayan son sətirinə diqqət yetirin. Bu o deməkdir ki, birbaşa yuxarıdakı etiket izahatlı bir etiketdir və həmin sətir izlənilmiş etiketin göstərdiyi commit-dir.

Git səyahətinizin bir nöqtəsində təsadüfən bir commit-i itirə bilərsiniz. Ümumiyyətlə, bu, üzərində işləyən bir branch-ı zorla sildiyiniz üçün baş verir və nəticədə branch-ı istədiyinizi ortaya qoyur; ya da bir branch-ı yenidən sıfırlayırsınız, beləliklə bir şey istədiyiniz commit-dən imtina edirsiniz. Bunun baş verdiyini düşünsək, commit-lərinizi necə geri ala bilərsiniz?

Test anbarınızdakı master branch-ı köhnə bir commit-ə yenidən bərpa edən və sonra itirilmiş commit-ləri bərpa edən bir nümunə göstərək. Əvvəlcə bu deponuzun harada olduğunu nəzərdən keçirək:

İndi, master branch-ınızı ortadakı commit-ə köçürün:

Ən yaxşı iki səmərəli işi itirmisiniz - bu commit-lərin əldə edilə biləcəyi bir branch-nız yoxdur. Ən son SHA-1 əmrini tapmalı və sonra ona işarə edən bir budaq əlavə etməlisiniz. Hiylə budur: son SHA-1 commit-ni tapmaq - bu yadınızda qalan kimi deyil, düzdür?

Çox vaxt, ən sürətli yol git reflog adlı bir vasitə istifadə etməkdir. İşləyərkən, Git hər dəfə dəyişdirdiyiniz zaman HEAD-in nə olduğunu səssizcə qeyd edir. Branch-ları hər dəfə işlətdiyiniz və ya dəyişdirdiyiniz zaman reflog yenilənir. Reflog ayrıca, Git Referansları-də qeyd etdiyimiz kimi, yalnız ref fayllarınıza SHA-1 dəyərini yazmaq əvəzinə istifadə etmək üçün başqa bir səbəb olan git update-ref əmri ilə də yenilənir. İstədiyiniz zaman harada olduğunuzu git reflog çalıştırarak görə bilərsiniz:

Burada yoxladığımız iki işi görə bilərik, lakin burada çox məlumat yoxdur. Eyni məlumatları daha faydalı bir şəkildə görmək üçün, git log -g işlədə bilərik ki, bu da reflog-unuz üçün normal bir günlük output-u təmin edəcəkdir.

Göründüyü kimi alt commit itirdiyiniz işdir, buna görə yeni commit yaratmaqla onu bərpa edə bilərsiniz. Məsələn, bu əməli (ab1afef) bərpa etmək üçün recover-branch başlada bilərsiniz:

Əla - indi recovery-branch adlı bir branch-nız var, əvvəllər master branch-nızın olduğu yerlərdə ilk iki iş yenidən əlçatandır. Bundan sonra, itkinizin bir səbəbdən reflog-da olmadığını düşünək – bunu recovery-branch-nı çıxarıb təkrar qeydini silməklə simulyasiya edə bilərsiniz. İndi ilk iki commit-ə heç bir şey çatmır:

Reflog məlumatları .git/logs/ qovluğunda saxlanıldığından, sizdə heç bir reflog yoxdur. Bu anda bu işi necə bərpa edə bilərsiniz? Bir üsul, verilənlər bazanızın bütövlüyünü yoxlayan git fsck yardım proqramından istifadə etməkdir. Bunu --full seçimi ilə işə salırsınızsa, başqa bir obyekt tərəfindən göstərilməyən bütün obyektləri göstərir:

Bu vəziyyətdə, “dangling commit” sətrindən sonra itkin commit-nizi görə bilərsiniz. Eyni SHA-1-ə işarə edən bir qol əlavə edərək onu eyni şəkildə bərpa edə bilərsiniz.

Git haqqında çox yaxşı şey var, amma bu problemə səbəb ola biləcək bir xüsusiyyətdir, yəni, bir git clone-un hər faylın hər versiyası da daxil olmaqla layihənin bütün tarixini yükləməsidir. Bu əgər mənbə kodu olarsa yaxşıdır, çünki Git bu məlumatları səmərəli şəkildə sıxmaq üçün yüksək dərəcədə optimize edilmişdir. Bununla birlikdə, layihənizin tarixinin hər hansı bir nöqtəsində kimsə tək bir nəhəng fayl əlavə etsə, bütün klonlar, sonrakı commit-lərdə layihədən çıxarılan olsa da, bütün zaman üçün bu klonu yükləmək məcburiyyətində qalacaq. Tarixdən əlçatan olduğundan həmişə mövcud olacaq.

Subversion və ya Perforce depolarını Git-ə çevirdiyiniz zaman bu böyük bir problem ola bilər. Bu sistemlərdəki bütün tarixi yükləmədiyiniz üçün bu əlavə bir neçə nəticəyə səbəb olur. Başqa bir sistemdən idxal etmisinizsə və ya başqa bir şəkildə deponuzun lazım olduğundan daha böyük olduğunu görmünüzsə, burada böyük obyektləri necə tapa və silə biləcəyinizi görə bilərsiniz.

Xəbərdarlıq: bu texnika sizin commit tarixçəniz üçün dağıdıcıdır. O, böyük bir fayl arayışını silmək üçün dəyişdirməli olduğunuz ilk ağacdan bəri hər bir commit obyektini yenidən yazır. Bunu idxaldan dərhal sonra, kimsə işin commit üzərində qurulmasına başlamazdan əvvəl etsəniz, yaxşıdır - əks halda, bütün dəstəkçilərinizə işlərini yeni commit-lərinizə qaytarmaları lazım olduğunu bildirməlisiniz.

Nümayiş üçün test deponuza böyük bir fayl əlavə edəcək, növbəti commit-də götürüb tapacaqsınız və depodan qalıcı olaraq çıxaracaqsınız. Əvvəlcə tarixçənizə böyük bir obyekt əlavə edin:

Vay - layihənizə böyük bir tarball əlavə etmək istəmirdiniz. Ən yaxşısı bundan yaxa qurtarmaq üçün:

İndi, məlumat bazanızı gc edin və nə qədər yer istifadə etdiyinizi görün:

Nə qədər yer istifadə etdiyinizi görmək üçün count-objects əmrini işə sala bilərsiniz:

Size-pack girişi paketlərinizin kilobayt ölçüsündədir, buna görə demək olar ki, 5MB istifadə edirsiniz. Son commit-dən əvvəl, 2K-a yaxın istifadə edirdiniz - açıq şəkildə, əvvəlki commit-dən faylın silinməsi tarixçənizdən silinmədi. Hər kəs bu deponu klonladıqda, yalnız bu kiçik layihəni əldə etmək üçün bütün 5 MB-ı klonlamalı olacaq, çünki siz təsadüfən böyük bir fayl əlavə etmisiniz. Gəlin bundan qurtulaq.

Əvvəlcə onu tapmaq lazımdır. Bu vəziyyətdə, bunun hansı fayl olduğunu artıq bilirsiniz. Ancaq güman etmədiniz ki; hansı fayl və ya sənədlərin bu qədər yer tutduğunu necə müəyyənləşdirərdiniz? git gc-i işlədirsinizsə, bütün obyektlər packfile-dadır; böyük obyektləri git verify-pack adlı başqa bir plumbing əmrini işə salmaqla və sənəddəki fayl ölçüsü olan üçüncü sahəyə görə ayırmaqla təyin edə bilərsiniz. Yalnız son bir neçə ən böyük sənədlə maraqlandığınız üçün onu tail əmri ilə ötürə bilərsiniz:

Aşağıdakı böyük obyekt: 5 MB. Hansı fayl olduğunu tapmaq üçün qısa müddətdə Xüsusi bir Commit-Mesaj Formatının Tətbiq Edilməsi-da istifadə etdiyiniz rev-list əmrini istifadə edəcəksiniz. --objects-i rev-list-ə keçirsəniz, bütün SHA-1’ləri və bunlarla əlaqəli fayl yolları ilə blob SHA-1’ləri siyahıya alır. Blob adınızı tapmaq üçün bundan istifadə edə bilərsiniz:

İndi keçmişdəki bütün ağaclardan bu faylı silməlisiniz. Bu faylı hansı commit-in dəyişdirdiyini asanlıqla görə bilərsiniz:

Bu faylı Git tarixinizdən tamamilə silmək üçün 7b30847-dən aşağıda olan bütün commit-ləri yenidən yazmalısınız. Bunu etmək üçün Tarixi Yenidən Yazmaq-də istifadə etdiyiniz filter-branch-dan istifadə edirsiniz:

--index-filter seçimi, Tarixi Yenidən Yazmaq-də istifadə olunan --tree-filter seçiminə bənzəyir, yalnız diskdə qeyd edilmiş sənədləri dəyişdirən bir əmr ötürmək əvəzinə, hər dəfə quruluş sahənizi və ya indeksinizi dəyişdirirsiniz.

Müəyyən bir faylı rm file kimi bir şeylə silmək əvəzinə, git rm --cached ilə silməlisiniz - diskdən yox, indeksdən çıxarmalısınız. Bunu bu şəkildə etməyinizin səbəbi sürətdir - çünki Git filterinizi işə salmadan əvvəl diskdəki hər bir düzəlişə baxmaq məcburiyyətində qalmadığı üçün proses çox daha sürətli ola bilər. Həmin tapşırığı --tree-filter ilə də yerinə yetirə bilərsiniz. git rm seçimi üçün --ignore-unmatch seçimi, silmək istədiyiniz şablonun olmadığı təqdirdə səhv etməməsini tələb edir. Nəhayət, filter-branch-dan tarixinizi yalnız 7b30847 commit-indən yenidən yazmasını xahiş edirsiniz, çünki bu problemin burada başladığını bilirsiniz. Əks təqdirdə, başlanğıcdan başlayacaq və lazımsız olaraq daha uzun çəkəcəkdir.

Tarixinizdə artıq həmin fayla istinad yoxdur. Bununla birlikdə reflogunuz və Git-in .git/refs/original altında filter-branch etdiyiniz zaman əlavə etdiyi yeni bir refs dəsti hələ də mövcuddur, buna görə onları silməli və sonra verilənlər bazasını yenidən paketləməlisiniz. Yenidən qablaşdırmadan əvvəl bu köhnə commit-lərə işarə edən bir şeydən qurtulmalısınız:

Gəlin nə qədər yer saxladığınıza baxaq:

Paketlənmiş depo ölçüsü 8K-a qədərdir, bu da 5MB-dən daha yaxşıdır. Ölçü dəyərindən görə bilərsiniz ki, böyük obyekt hələ də boş obyektlərinizdədir, buna görə də getməyib; lakin vacib olan odur ki, o, push və ya sonrakı bir klon üzərinə köçürülməyəcəkdir. Həqiqətən istəsəniz, --expire seçimi ilə git prune düyməsini basaraq obyekti tamamilə silə bilərsiniz: