8.1 Git’i Fərdiləşdirmək - Git Konfiqurasiyası

Standart olaraq, Git, vizual mətn redaktoru olaraq təyin etdiyiniz hər şeyi VISUAL və ya EDITOR shell mühiti dəyişənlərindən biri vasitəsilə istifadə edir və ya commit-lərinizi düzəltmək və etiketləmək üçün vi redaktoruna qayıdır. Standart olanı başqa bir şeyə dəyişdirmək üçün core.editor ayarını istifadə edə bilərsiniz:

İndi, standart shell redaktorunuz kimi təyin olunmasından asılı olmayaraq, Git mesajları düzəltmək üçün Emacs-ı işə salacaq.

Bunu sisteminizdəki bir fayl path-a düzəltmisinizsə, Git bu fayldan commit götürdüyünüzdə ilkin mesaj olaraq istifadə edəcəkdir. Xüsusi bir commit şablonu yaratmağın dəyəri, bir commit mesajı yaradarkən özünüzə (və ya başqalarına) uyğun format və üslubu xatırlatmaq üçün istifadə edə bilərsiniz.

Məsələn, ~/.gitmessage.txt ünvanındakı bir şablon faylını nəzərdən keçirin:

Bu commit şablonunun vəzifələndiriciyə mövzu sətrini qısa saxlamağı (git log --oneline çıxışı naminə), bunun altına daha çox təfərrüat əlavə etməsini və mövcud olduqda bir problemə və ya səhv izləyici bilet nömrəsinə istinad etməsini necə xatırlatdığına diqqət yetirin.

Git-ə, git commit-i işə saldığınız zaman redaktorunuzda görünən standart mesaj kimi istifadə etməsini söyləmək üçün, commit.template konfiqurasiya dəyərini təyin edin:

Bundan sonra, redaktorunuz, commit zamanı placeholder commit mesajı üçün belə bir şey açacaq:

Komandanızın bir commit mesajı siyasəti varsa, bu siyasət üçün bir şablon sisteminizə qoymaq və Git’i standart olaraq istifadə etmək üçün konfiqurasiya etmək, bu siyasətin mütəmadi olaraq izlənmə şansını artırmağa kömək edə bilər.

Bu parametr, Git səhifələrinin log və diff kimi output-u zamanı hansı pager cihazının istifadə olunduğunu təyin edir. Onu more ya da sevdiyiniz pager cihazına qura bilərsiniz (standart olaraq, daha less-dir) və ya boş bir sətir quraraq söndürə bilərsiniz:

Bunu işləsəniz, Git, nə qədər olmasına baxmayaraq bütün əmrlərin bütün output-nu səhifələndirəcəkdir.

İmzalı şərhli etiketlər düzəldirsinizsə (İşinizin İmzalanması də müzakirə edildiyi kimi), GPG imzalama key-nizi konfiqurasiya ayarı olaraq təyin etmək işləri asanlaşdırır. Key ID-nizi belə ayarlayın:

İndi hər dəfə git tag əmri ilə key-nizi göstərmədən etiketlər imzalaya bilərsiniz:

Layihənizin .gitignore sənədinə nümunələr qoya bilərsiniz ki, Git onları izlənilməmiş fayllar kimi görməsin və ya Nəzərə Alınmayan Fayllar də deyildiyi kimi onlara git add işlədərkən səhnələşdirməyə çalışın.

Ancaq bəzən işlədiyiniz bütün depolar üçün müəyyən sənədləri görməməzlikdən gəlmək istəyərsiniz. Kompüterinizdə macOS işləyirsə, ehtimal ki, .DS_Store faylları ilə tanışsınız. Tercih etdiyiniz redaktor Emacs və ya Vim-dirsə, ~ və ya .swp ilə bitən fayl adlarını da bilirsiniz.

Bu parametr bir növ qlobal .gitignore faylı yazmağınıza imkan verir. Bu məzmunu olan bir ~/.gitignore_global faylı yaratsanız:

…və git config --global core.excludesfile ~/.gitignore_global işə salsanız, Git bir daha bu fayllarla sizi narahat etməyəcəkdir.

Əgər əmri səhv yazsanız, sizə belə bir şey göstərəcək:

Git köməkliklə nə demək istədiyinizi anlamağa çalışır, amma yenə də bunu etməkdən imtina edir. help.autocorrect-i 1 olaraq təyin etsəniz, Git bu əmri həqiqətən sizin üçün işlədəcək:

Qeyd edək ki, “0.1 seconds” işi help.autocorrect əslində saniyənin onda birini təmsil edən bir tam rəqəmdir. Buna görə 50-yə qoysanız, Git, avtomatik düzəliş əmrini yerinə yetirmədən əvvəl fikrinizi dəyişdirmək üçün 5 saniyə verəcəkdir.

Git output-un çox hissəsini avtomatik olaraq rəngləndirir, ancaq bunu bəyənməsəniz, master-ə keçid var. Bütün Gitin rəngli terminal output-nu söndürmək üçün bunu edin:

Standart ayar auto-dur, hansı rənglər output-dursa, onda birbaşa terminala gedir, amma output bir pipe və ya bir fayla yönəldildikdə o zaman rəng nəzarət kodlarını nəzərdən buraxır.

Terminallar və pipe-lar arasındakı fərqi görməməzlikdən gəlmək üçün onu always olaraq da qura bilərsiniz.

Bunu nadir hallarda istəyəcəksiniz; əksər ssenarilərdə, yönləndirilmiş output-unuzda rəng kodları istəsəniz, bunun əvəzinə rəng kodlarını istifadə etməyə məcbur etmək üçün Git əmrinə bir --color flag-ını ötürə bilərsiniz. Standart ayar demək olar ki, həmişə istədiyiniz şeydir.

Hansı əmrlərin və necə rəngləndiyinə dair daha konkret olmaq istəyirsinizsə, Git verb-spesific rəngləmə parametrlərini təqdim edir. Bunların hər biri true, false və ya always olaraq təyin edilə bilər:

Bundan əlavə, bunların hər birində, hər bir rəngin üstündən keçmək istəsəniz, output hissələri üçün xüsusi rənglər təyin etmək üçün istifadə edə biləcəyiniz alt parametrlər var. Məsələn, fərqli çıxışınızdakı meta məlumatını mavi ön planda, qara fonda və qalın mətn olaraq təyin etmək üçün aşağıdakıları edə bilərsiniz:

Rəngi aşağıdakı dəyərlərdən hər hansı birinə qura bilərsiniz: normal, black, red, green, yellow, blue, magenta, cyan, və ya white. Əvvəlki nümunədəki kimi qalın bir atribut istəsəniz, bold, dim, ul (underline), blink, and reverse (swap foreground və background) seçə bilərsiniz.

Windows-da proqram hazırlayırsınızsa və olmayan insanlarla işləyirsinizsə (və ya əksinə), ehtimal ki, bir nöqtədə sətir sonuna çatanda problemlərlə qarşılaşacaqsınız. Bunun səbəbi, Windows-un fayllarında həm satır qayıtma xarakteri, həm də yeni xətlər üçün xətt xarakteri istifadə etməsi, MacOS və Linux sistemlərində isə yalnız xətt xarakteri istifadə etməsidir. Bu, cross-platform işinin incə, lakin inanılmaz dərəcədə cansıxıcı bir həqiqətidir; Windows-dakı bir çox redaktor səssizcə mövcud LF stili sətir uclarını CRLF ilə əvəz edir və ya istifadəçi giriş düyməsini vurduqda hər iki sətir işarəsini əlavə edir.

Git, indeksə bir fayl əlavə etdiyiniz zaman CRLF sətir sonlarını avtomatik olaraq LF-ə çevirməklə və əksinə fayl sisteminizə kodu yoxladıqda bunu edə bilər. Bu funksiyanı core.autocrlf ayarı ilə aça bilərsiniz. Bir Windows qurğusundasınızsa, onu true olaraq ayarlayın - bu kodu yoxladığınız zaman LF sonluqlarını CRLF-ə çevirir:

Əgər LF sətir sonluqlarından istifadə edən bir Linux və ya macOS sistemindəsinizsə, faylları yoxlayarkən Git-in onları avtomatik olaraq çevirməsini istəmirsiniz; Bununla birlikdə, CRLF sonlu bir fayl təsadüfən təqdim edilərsə, Git-in düzəltməsini istəyə bilərsiniz. Git-ə, core.autocrlf-ni girişə ayarlayaraq CRLF-i commit götürdükdə LF-yə çevirməsini söyləyə bilərsiniz:

Bu quraşdırma sizi Windows checkout-larında CRLF sonları ilə qoymalıdır, lakin macOS və Linux sistemlərində və depoda LF sonluqlarıdır.

Yalnız bir Windows layihəsi həyata keçirən bir Windows proqramçısınızsa, konfiqurasiya dəyərini false olaraq təyin edərək daşıma ehtiyatını depoda qeyd edərək bu funksiyanı söndürə bilərsiniz:

Git, bəzi whitespace problemlərini aşkarlamaq və düzəltmək üçün əvvəlcədən hazırlanmışdır. O, altı əsas whitespace məsələsinə baxa bilər - üçü standart olaraq aktivdir və söndürülə bilər və üçü standart olaraq deaktivdir, lakin aktivləşdirilə bilər. Standart olaraq açılan üçü bir sətrin sonunda boşluq axtaran blank-at-eol; bir sənədin sonunda boş sətirləri görən blank-at-eof; və bir sətrin əvvəlindəki nişanlardan əvvəl boşluqlar axtaran space-before-tab.

Standart olaraq deaktiv edilmiş, lakin açıla bilən üç nişanlar əvəzinə boşluqlarla başlayan sətirləri axtaran (və tabwidth seçimi ilə idarə olunan) olan indent-with-non-tab-dir; bir sətrin girinti hissəsindəki nişanları izləyən tab-in-indent; və Git-ə sətirlərin sonunda carriage qayıtmalarının yaxşı olduğunu bildirən cr-at-eol.

Bunlardan hansının işə salınmasını istədiyinizi vergüllə ayrılmış və ya söndürmək istədiyiniz dəyərlərə core.whitespace ayarlayaraq söyləyə bilərsiniz. Bir seçimi adının önünə - yazaraq söndürə və ya tamamilə ayar sətrindən kənarda qoyaraq standart dəyəri istifadə edə bilərsiniz.

Məsələn, space-before-tab başqa hamısının qurulmasını istəyirsinizsə, bunu edə bilərsiniz (trailing-space həm blank-at-eol həm də blank-at-eof əhatə edəcək short-hand-dir):

Və ya yalnız özəlləşdirmə hissəsini təyin edə bilərsiniz:

Git, git diff əmri işlədərkən bu problemləri aşkarlayacaq və onları rəngləməyə çalışacaq, belə ki, siz onları etmədən əvvəl düzəldə bilərsiniz. Ayrıca, git apply ilə patch-lar tətbiq etdikdə sizə kömək etmək üçün bu dəyərlərdən istifadə edəcəkdir.

Patch-lar tətbiq edərkən, Git-dən göstərilən whitespace məsələləri ilə patch-lar tətbiq edərsə sizi xəbərdar etməsini istəyə bilərsiniz:

Ya da Git patch tətbiq etməzdən əvvəl problemi avtomatik olaraq həll etməyə çalışa bilərsiniz:

Bu seçimlər git rebase əmrinə də aiddir. Əgər whitespace problemi yaratmısınız, lakin hələ də yuxarıya doğru push etməmisinizsə, Git-in boşluqları yenidən yazdığı üçün whitespace problemini avtomatik olaraq düzəltməsini təmin etmək üçün git rebase --whitespace=fix düyməsini işə sala bilərsiniz.

Git, push zamanı alınan hər bir obyektin hələ də SHA-1 hesablama məbləğinə uyğun gəldiyini və etibarlı obyektləri göstərdiyini təmin edə bilər. Ancaq bunu standart olaraq etmir; bu olduqca bahalı bir əməliyyatdır və xüsusən böyük depolarda və ya push-larda əməliyyatı ləngidə bilər. Git-in hər push üzərində obyekt uyğunluğunu yoxlamasını istəyirsinizsə, bunu receive.fsckObjects-i true olaraq təyin edərək məcbur edə bilərsiniz:

İndi, Git, hər bir push qəbul edilməzdən əvvəl səhvli (və ya zərərli) müştərilərin pozulmuş məlumatları təqdim etməməsinə əmin olmaq üçün deponuzun bütövlüyünü yoxlayacaqdır.

Əgər siz artıq push etdiyiniz commit-nizi geri qaytarsanız və sonra yenidən push etməyə çalışsanız və ya başqa bir şəkildə uzaq branch-ın göstərdiyi commit-i ehtiva etməyən bir remote branch-a push etməyə çalışarsanız, rədd ediləcəksiniz. Bu ümumiyyətlə yaxşı siyasətdir; lakin geri qaytarma vəziyyətində nə etdiyinizi bildiyinizi və remote branch-ı -f flag-ı ilə push əmrinizə məcburi şəkildə yeniləyə biləcəyinizi müəyyən edə bilərsiniz.

Git-ə güc tətbiqetməsindən imtina etməsini söyləmək üçün receive.denyNonFastForwards seçin:

Bunu edə biləcəyiniz başqa bir yol, server tərəfdən qəbul hook-larıdır və onları indi bir az əhatə edəcəyik. Bu yanaşma, müəyyən bir istifadəçi qrupuna sürətli olmayan hücumları inkar etmək kimi daha mürəkkəb şeylər etməyə imkan verir.

denyNonFastForwards siyasətinin həll yollarından biri də istifadəçinin branch-ı silmək və sonra yeni istinadla geri push etməsidir. Bunun qarşısını almaq üçün, receive.denyDeletes-i true olaraq seçin:

Bu, branch və ya etiketlərin silinməsini inkar edir - heç bir istifadəçi bunu edə bilməz. Remote branch-ları silmək üçün ref fayllarını serverdən manual şəkildə çıxarmalısınız. Bunu ACL-lər vasitəsilə hər istifadəçi bazasında etmək üçün daha maraqlı yollar var, hansı ki Git-Enforced Siyasət Nümunəsi-də öyrənəcəksiniz.