7.10 Git Alətləri - Git ilə Debugging

Kodunuzdakı bir səhvi izləyirsinizsə və onun nə vaxt tətbiq olunduğunu və nə üçün olduğunu bilmək istəyirsinizsə, fayl annotasiyası çox vaxt ən yaxşı vasitədir. O sizə hər hansı bir faylın hər sətirini dəyişdirmək üçün son commit-i göstərir. Aşağıdakı nümunə, üst səviyyəli Linux kernel Makefile-də və daha sonra hansı commit və committer-in cavabdeh olduğunu müəyyən etmək üçün git balme-dən istifadə edir, bundan əlavə loqotipin output-nu həmin sənədin 69-dan 82-yə qədər olan xətləri ilə məhdudlaşdırmaq üçün `-L `seçimindən istifadə edir:

Diqqət yetirin ki, ilk sahə həmin xətti son dəyişdirən commit-in qismən SHA-1 hissəsidir. Növbəti iki sahə həmin commit-dən çıxarılan dəyərlərdir - müəllifin adı və həmin commit-in müəllif tarixi - bu xətti kimin və nə vaxt dəyişdirdiyini asanlıqla görə bilərsiniz. Bundan sonra xətt nömrəsi və faylın məzmunu gəlir. Həm də ^1da177e4c3f4 commit xətlərinə diqqət yetirin, burada ^ prefiksi deposunun ilkin commit-ə daxil edilmiş və indiyədək dəyişməmiş xətləri təyin edir. Bu çaşdırıcı bir şeydir, çünki indi Git-in SHA-1-i dəyişdirmək üçün ^-dan istifadə etdiyi ən az üç fərqli üsulu gördünüz, amma burada da bunun mənası budur.

Git’in başqa bir xoş cəhəti, fayl adlarını açıq şəkildə izləməməsidir. O, bu anları qeyd edir və sonra gerçəkləşdirildikdən sonra adının dəyişdirildiyini anlamağa çalışır. Bunun maraqlı xüsusiyyətlərindən biri odur ki, hər cür kod hərəkətini də anlamağını istəyə bilərsiniz. Əgər –C-ni git blame-ə ötürsəniz, Git yazdığınız faylı təhlil edir və başqa yerdən kopyalandığı təqdirdə içərisindəki kod parçalarının haradan gəldiyini anlamağa çalışır. Məsələn, GITServerHandler.m adlı bir faylı GITPackUpload.m`olan birdən çox sənədə refactoring etdiyinizi fərz edək. `GITPackUpload.m-u -C seçimi ilə blame edərək kodun bölmələrinin əvvəlcə haradan gəldiyini görə bilərsiniz:

Bu həqiqətən faydalıdır. Normalda, kodun surətini çıxardığınız zaman orijinal commit-i götürdüyünüz üçün alırsınız, çünki bu sənəddəki bu sətirlərə ilk dəfə toxunursunuz. Git, başqa bir sənəddə olsa belə, bu sətirləri harada yazdığınızın orijinal commit-ni bildirir.

Bir faylın qeyd edilməsi, əgər məsələnin nədən başlayacağını bilirsinizsə kömək edir. Əgər nəyin pozulduğunu bilmirsinizsə və kodun işlədiyini bildiyiniz son vəziyyətdən bəri onlarla və yüzlərlə iş görülmüşdürsə, çox güman ki, kömək üçün git bisect-ə müraciət edə bilərsiniz. bisect əmri bir problemi ortaya qoyduğunu mümkün qədər tez müəyyənləşdirməyə kömək etmək üçün commit tarixçənizlə ikili axtarış aparır.

Deyək ki, kodunuzu bir istehsal mühitinə push etdiniz, inkişaf mühitinizdə baş verməyən bir şey haqqında bug hesabatları alırsınız və kodun niyə belə etdiyini təsəvvür edə bilmirsiniz. Kodunuza qayıdırsınız və məsələni yenidən yarada biləcəyiniz ortaya çıxır, ancaq nəyin səhv olduğunu anlaya bilmirsiniz. Bunu bilmək üçün kodu bisect edə bilərsiniz. Əvvəlcə git bisect-i işə salın, sonra sistemin hazırkı commit-in pozulduğunu söyləmək üçün git bisect bad istifadə edin. Daha sonra, git bisect good <good_commit> istifadə edərək, son məlum olan yaxşı vəziyyətin nə vaxt olduğunu bisect-ə deməlisiniz.

Git anlayır ki, son yaxşı commit (v1.0) kimi qeyd edilmiş commit-lə hazırkı pis versiya arasında təxminən 12 əmr gəlir və bu sizin üçün orta birini yoxlayır. Bu anda, problemin bu commit-ə görə olub olmadığını görmək üçün testinizi işə sala bilərsiniz. Bunu edərsə, onda bu orta commit-dən bir müddət əvvəl tətbiq edilmişdir; etmirsə, problem orta commit-dən bir müddət sonra ortaya çıxır. Buradan heç bir problem çıxmır və Git’ə git bisect good yazaraq işinizi davam etdirdiyinizi deyə bilərsiniz:

İndi siz sınadığınızla pis commit-in yarısının ardınca gələn başqa bir commit-dəsiniz. Yenidən testinizi həyata keçirirsiniz və bu commit-in pozulduğunu görürsünüz, buna görə git bisect bad ilə Git-ə deyirsiniz:

Bu commit yaxşıdır və indi Git məsələnin harada tətbiq olunduğunu müəyyənləşdirmək üçün lazım olan bütün məlumatlara sahibdir. Bu sizə ilk pis commit-ə aid SHA-1 deyir və commit məlumatlarının bəzilərini göstərir və bu bug-da hansı hadisələrin baş verdiyini anlamaq üçün bu sənəddə nəyin dəyişdirildiyini göstərir:

Bitirdikdən sonra başlamazdan əvvəl olduğunuz yeri bərpa etmək üçün git bisect reset işlətməlisiniz, yoxsa qəribə bir vəziyyətə düşəcəksiniz:

Bu, bir neçə dəqiqə ərzində təqdim edilmiş bir bug üçün yüzlərlə commit-i yoxlamağa kömək edə biləcək güclü bir vasitədir. Əslində, 0-dan çıxacaq bir ssenariniz varsa, əgər layihə yaxşıdırsa və ya 0-dan pisdirsə, layihə ümumilikdə pisdirsə, git bisect-ini tam avtomatlaşdıra bilərsiniz. Birincisi, məlum pis və yaxşı əmrləri verməklə yenidən bisetin həcmini söyləyin. İstədiyiniz təqdirdə bisect start əmri ilə siyahıya alınmaqla, məlum pis commit-i birinci və məlum yaxşı commit-i ikinci sıralamaqla bunu edə bilərsiniz:

Bunu etmək Git ilk pozulmuş commit-ni tapana qədər hər test edilmiş test-error.sh üzərində avtomatik olaraq işə salır. Siz həmçinin testlər edə bilə və ya sizin üçün avtomatlaşdırılmış testləri işlədən hər hansı bir şeyi işlədə bilərsiniz.