Git 🌙
Chapters ▾ 2nd Edition

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

İndiyə qədər Git’in necə işlədiyini və necə istifadə ediləcəyini izah etdik və asanlıqla və səmərəli istifadə etməyiniz üçün Git’in təqdim etdiyi bir sıra vasitələri təqdim etdik. Bu fəsildə bir neçə vacib konfiqurasiya parametrlərini və hook’lar sistemini təqdim edərək Git’i daha çox fərdi qaydada necə işlədə biləcəyinizi görəcəyik. Bu vasitələrlə Git’in sizin, şirkətinizin və ya qrupunuzun ehtiyac duyduğu şəkildə işləməsini təmin etmək asandır.

Git Konfiqurasiyası

Qısa şəkildə Başlanğıc-da oxuduğumuz kimi, Git konfiqurasiyasını git config əmri ilə tənzimləyə bilərsiniz. Etdiyiniz ilk işlərdən biri adınızı və e-poçt adresinizi qurmaq idi:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

İndi Git istifadənizi fərdiləşdirmək üçün bu şəkildə təyin edə biləcəyiniz daha maraqlı variantlardan bir neçəsini öyrənəcəksiniz.

Birincisi, sürətli bir nəzərdən keçirmə: Git, istəyə biləcəyiniz qeyri-standart davranışı təyin etmək üçün bir sıra konfiqurasiya fayllarından istifadə edir.

Git-in bu dəyərləri axtardığı ilk yer sistemdəki bütün istifadəçilərə və onların bütün depolarına tətbiq olunan parametrləri ehtiva edən sistem səviyyəsində /etc/gitconfig faylındadır. --system seçimini git config-ə pass etsəniz, o xüsusilə bu fayldan oxuyur və yazır.

Git’in növbəti göründüyü yer hər bir istifadəçiyə xas olan ~/.gitconfig (və ya ~/.config/git/config) faylıdır. Git-i bu --global seçiminə pass edərək bu faylı oxumağa və yazmağa məcbur edə bilərsiniz.

Nəhayət, Git, istifadə etdiyiniz hər hansı bir deponun Git qovluğundakı (.git/config) konfiqurasiya faylındakı konfiqurasiya dəyərlərini axtarır. Bu dəyərlər həmin tək olan depoya xasdır və --local seçiminin git config-ə pass edilməsini təmsil edir. Hansı səviyyə ilə işləmək istədiyinizi müəyyənləşdirməmisinizsə, bu standartdır.

Bu “levels” (sistem, qlobal, yerli) hər biri əvvəlki səviyyə üzərində yazır, buna görə .git/config-dəki dəyərlər, məsələn, /etc/gitconfig dəki şeyləri qazanır.

Note

Git-in konfiqurasiya sənədləri sadə mətndir, buna görə də bu dəyərləri faylı manual olaraq düzəldərək və düzgün sintaksisini əlavə edərək təyin edə bilərsiniz. Hərçənd, git config əmrini çalışdırmaq ümumiyyətlə daha asandır.

Sadə Müştəri Konfiqurasiyası

Git tərəfindən tanınan konfiqurasiya seçimləri iki kateqoriyaya bölünür: müştəri və server tərəfi. Seçimlərin əksəriyyəti müştəri tərəfli — configurating yəni şəxsi iş seçimlərinizdir. Bir çox, çox konfiqurasiya variantı dəstəklənir, lakin bunların böyük bir hissəsi yalnız müəyyən kənar hallarda faydalıdır; burada ən çox yayılmış və faydalı variantları nəzərdən keçirəcəyik. Git versiyanızın tanıdığı bütün seçimlərin siyahısını görmək istəyirsinizsə, aşağıdakıları edə bilərsiniz:

$ man git-config

Bu əmrdə mövcud olan bütün seçimlər bir az ətraflı şəkildə sadalanır. Bu istinad materialını https://git-scm.com/docs/git-config səhifəsində də tapa bilərsiniz.

core.editor

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:

$ git config --global core.editor emacs

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

commit.template

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:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

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:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

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

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

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.

core.pager

Bu parametr, Git səhifələrinin logdiff 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:

$ git config --global core.pager ''

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.

user.signingkey

İ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:

$ git config --global user.signingkey <gpg-key-id>

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

$ git tag -s <tag-name>

core.excludesfile

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:

*~
.*.swp
.DS_Store

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

help.autocorrect

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

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

Buna ən bənzər əmr checkout-dur.

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:

$ git chekcout master
DİQQƏT: Siz mövcud olmayan 'chekcout' adlı bir Git əmri çağırmısınız.
'Checkout' demək istədiyiniz fərziyyəsi ilə 0.1 saniyədə davam edin...

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-də Rənglər

Git, komanda çıxışını tez və asanlıqla vizual olaraq təhlil etməyə kömək edən rəngli terminal çıxışını tamamilə dəstəkləyir. Bir sıra seçimlər rənglənməni seçiminizə uyğunlaşdırmağa kömək edə bilər.

color.ui

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:

$ git config --global color.ui false

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.

color.*

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:

color.branch
color.diff
color.interactive
color.status

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:

$ git config --global color.diff.meta "blue black bold"

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.

Xaricdən Birləşdirmə və Diff Vasitələri

Git’in bu kitabda göstərdiyimiz fərqli bir diff tətbiqinə sahib olmasına baxmayaraq bunun əvəzinə xarici bir vasitə qura bilərsiniz. Konfliktləri manual şəkildə həll etmək əvəzinə qrafik merge-conflict-resolution vasitəsini də qura bilərsiniz. Diff-lərinizi yerinə yetirmək və nəticələrinizi birləşdirmək üçün Perforce Visual Merge Tool (P4Merge) qurmağı nümayiş etdirəcəyik, çünki gözəl bir qrafik vasitədir və ödənişsizdir. Bunu sınamaq istəyirsinizsə, P4Merge bütün əsas platformalarda işləyir, buna görə də bunu bacaracaqsınız. MacOS və Linux sistemlərində işləyən nümunələrdə path adlarını istifadə edəcəyik; Windows üçün mühitinizdə /usr/local/bin-i icra oluna bilən bir path-a dəyişdirməlisiniz.

Başlamaq üçün, download P4Merge from Perforce. Sonra, əmrlərinizi işə salmaq üçün xarici bağlama skriptlərini quracaqsınız. İştifadə oluna bilənlər üçün macOS yolunu istifadə edəcəyik; digər sistemlərdə, p4merge ikilinizin quraşdırıldığı yer olacaq. Verilən bütün arqumentlərlə ikili çağıran extMerge adlı birləşdirmə wrapper skriptini qurun:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

Diff wrapper yeddi arqumentin verildiyini yoxlayır və onlardan ikisini birləşmə ssenarinizə ötürür. Standart olaraq, Git diff proqramına aşağıdakı arqumentləri ötürür:

path old-file old-hex old-mode new-file new-hex new-mode

Yalnız old-filenew-file arqumentlərini istədiyiniz üçün ehtiyac duyduqlarınızı ötürmək üçün wrapper skriptindən istifadə edirsiniz.

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

Həm də bu alətlərin icra oluna biləcəyinə əmin olmalısınız:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

İndi konfiqurasiya sənədinizi xüsusi birləşdirmə qərarından və diff alətlərindən istifadə etmək üçün qura bilərsiniz. Bunun üçün bir sıra xüsusi ayarlar lazımdır: Git-ə hansı strategiyanı istifadə edəcəyini söyləmək üçün merge.tool, mergetool.<tool>.cmd əmrinin necə işlədiləcəyini göstərmək üçün, mergetool.<tool>.trustExitCode, Git-ə deyin. Bu proqramın çıxış kodu xüsusi birləşmə qərarını göstərir və ya göstərmirsə və Git-ə difflər üçün hansı əmri çalıştıracağını söyləmək üçün diff.external yoxlayın. Beləliklə, dörd konfiqurasiya əmrini işə sala bilərsiniz:

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
  'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

Və ya bu sətirləri əlavə etmək üçün ~/.gitconfig faylını yoxlaya bilərsiniz:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

Bütün bunlar qurulduqdan sonra, bu kimi diff əmrləri işlədirsinizsə:

$ git diff 32d1776b1^ 32d1776b1

Əmr sətrində diff output-u əldə etmək əvəzinə, Git P4Merge-i işə salır, buna bənzər bir şey görünür:

P4Merge
Figure 143. P4Merge

İki branch-ı birləşdirməyə və daha sonra birləşmə konfliktlərinə sahib olsanız, git mergetool əmrini işə sala bilərsiniz; bu GUI vasitəsi ilə konfliktləri həll etməyiniz üçün P4Merge başladır.

Bu wrapper quruluşunun ən yaxşı tərəfi odur ki, diff-lərinizi dəyişə və alətlərinizi asanlıqla birləşdirə bilərsiniz. Məsələn, bunun əvəzinə KDiff3 alətini işə salmaq üçün extDiffextMerge alətlərinizi dəyişdirmək üçün yalnız extMerge sənədinizi düzəltməlisiniz:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

İndi Git, diff qərarını və konflikt həllini birləşdirmək üçün KDiff3 alətini istifadə edəcəkdir.

Git, cmd konfiqurasiyasını qurmadan bir sıra digər birləşmə qərarı alətlərindən istifadə etmək üçün əvvəlcədən hazırlanmışdır. Dəstəklədiyi alətlərin siyahısını görmək üçün bunu sınayın:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

KDiff3-ü diff üçün istifadə etməklə maraqlanmırsınız, əksinə onu yalnız birləşdirmə həlli üçün istifadə etmək istəyirsinizsə və kdiff3 əmri sizin path-dadırsa, o zaman işə sala bilərsiniz:

$ git config --global merge.tool kdiff3

Bunu extMergeextDiff fayllarını qurmaq əvəzinə işlətsəniz, Git birləşmə qərarı üçün KDiff3’ü və difflər üçün normal Git diff alətini istifadə edəcəkdir.

Formatlama və Whitespace

Formatlama və whitespace məsələləri, bir çox developer-in, xüsusilə cross-platform-da əməkdaşlıq edərkən qarşılaşdıqları daha əsəb pozucu və incə problemlərdən biridir. Patch-lar və ya digər işlərdə incə whitespace dəyişikliklərini tətbiq etmək çox asandır, çünki redaktorlar səssizcə təqdim edirlər və sənədləriniz hər hansı bir Windows sisteminə toxunarsa, xətt uçları dəyişdirilə bilər. Git-in bu məsələlərdə kömək edəcək bir neçə konfiqurasiya variantı var.

core.autocrlf

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:

$ git config --global core.autocrlf true

Ə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:

$ git config --global core.autocrlf input

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 config --global core.autocrlf false

core.whitespace

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):

$ git config --global core.whitespace \
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

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

$ git config --global core.whitespace \
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

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:

$ git apply --whitespace=warn <patch>

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

$ git apply --whitespace=fix <patch>

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.

Server Konfiqurasiyası

Git-in server tərəfi üçün o qədər də konfiqurasiya seçimi mövcud deyil, ancaq qeyd etmək istəyə biləcəyiniz bir neçə maraqlı seçim var.

receive.fsckObjects

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:

$ git config --system receive.fsckObjects true

İ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.

receive.denyNonFastForwards

Ə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:

$ git config --system receive.denyNonFastForwards true

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.

receive.denyDeletes

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:

$ git config --system receive.denyDeletes true

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.

scroll-to-top