-
1. Başlanğıc
- 1.1 Versiyaya Nəzarət Haqqında
- 1.2 Git’in Qısa Hekayəsi
- 1.3 Git Nədir?
- 1.4 Əmr Sətiri
- 1.5 Git’i Quraşdırmaq
- 1.6 İlk Dəfə Git Quraşdırması
- 1.7 Kömək Almaq
- 1.8 Qısa Məzmun
-
2. Git’in Əsasları
-
3. Git’də Branch
- 3.1 Nutshell’də Branch’lar
- 3.2 Sadə Branching və Birləşdirmə
- 3.3 Branch İdarəedilməsi
- 3.4 Branching İş Axınları
- 3.5 Uzaq Branch’lar
- 3.6 Rebasing
- 3.7 Qısa Məzmun
-
4. Server’də Git
- 4.1 Protokollar
- 4.2 Serverdə Git Əldə Etmək
- 4.3 Sizin öz SSH Public Key’nizi yaratmaq
- 4.4 Server qurmaq
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Tərəf Seçimləri
- 4.10 Qısa Məzmun
-
5. Paylanmış Git
-
6. GitHub
-
7. Git Alətləri
- 7.1 Reviziya Seçimi
- 7.2 Interaktiv Səhnələşdirmə
- 7.3 Stashing və Təmizləmə
- 7.4 İşinizin İmzalanması
- 7.5 Axtarış
- 7.6 Tarixi Yenidən Yazmaq
- 7.7 Reset Demystified
- 7.8 İnkişaf etmiş Birləşmə
- 7.9 Rerere
- 7.10 Git ilə Debugging
- 7.11 Alt Modullar
- 7.12 Bundling
- 7.13 Dəyişdirmək
- 7.14 Etibarlı Yaddaş
- 7.15 Qısa Məzmun
-
8. Git’i Fərdiləşdirmək
- 8.1 Git Konfiqurasiyası
- 8.2 Git Atributları
- 8.3 Git Hook’ları
- 8.4 Git-Enforced Siyasət Nümunəsi
- 8.5 Qısa Məzmun
-
9. Git və Digər Sistemlər
- 9.1 Git Müştəri kimi
- 9.2 Git’ə Miqrasiya
- 9.3 Qısa Məzmun
-
10. Git’in Daxili İşləri
- 10.1 Plumbing və Porcelain
- 10.2 Git Obyektləri
- 10.3 Git Referansları
- 10.4 Packfile’lar
- 10.5 Refspec
- 10.6 Transfer Protokolları
- 10.7 Maintenance və Məlumatların Bərpası
- 10.8 Mühit Dəyişənləri
- 10.9 Qısa Məzmun
-
A1. Appendix A: Digər Mühitlərdə Git
- A1.1 Qrafik interfeyslər
- A1.2 Visual Studio’da Git
- A1.3 Visual Studio Code’da Git
- A1.4 Eclipse’də Git
- A1.5 Sublime Text’də Git
- A1.6 Bash’da Git
- A1.7 Zsh’də Git
- A1.8 PowerShell’də Git
- A1.9 Qısa Məzmun
-
A2. Appendix B: Proqramlara Git Daxil Etmək
- A2.1 Əmr-sətri Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Git Əmrləri
- A3.1 Quraşdırma və Konfiqurasiya
- A3.2 Layihələrin Alınması və Yaradılması
- A3.3 Sadə Snapshotting
- A3.4 Branching və Birləşmə
- A3.5 Layihələrin Paylaşılması və Yenilənməsi
- A3.6 Yoxlama və Müqayisə
- A3.7 Debugging
- A3.8 Patching
- A3.9 E-poçt
- A3.10 Xarici Sistemlər
- A3.11 İdarəetmə
- A3.12 Plumbing Əmrləri
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, |
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 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:
$ 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-file
və new-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](png/p4merge.png)
İ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 extDiff
və extMerge
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 extMerge
və extDiff
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.