config.asc

Konfiguracija Git

Kot ste na kratko prebrali v poglavju ch01-getting-started.asc, lahko s pomočjo ukaza git config nastavite konfiguracijske nastavitve Git. Eden izmed prvih korakov je bil, da ste nastavili svoje ime in e-poštni naslov:

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]

Sedaj boste spoznali nekaj bolj zanimivih možnosti, ki jih lahko na ta način nastavite, da prilagodite uporabo Gita.

Najprej hiter povzetek: Git uporablja niz konfiguracijskih datotek, da določi obnašanje, ki ni privzeto. Prvo mesto, kjer Git išče te vrednosti, je sistemska datoteka [path]/etc/gitconfig, ki vsebuje nastavitve, ki se uporabljajo za vsakega uporabnika v sistemu in za vse njihove repozitorije. Če pri git config podate možnost --system, se prebere in piše izključno iz te datoteke.

Naslednje mesto, kjer Git išče, je datoteka ~/.gitconfig (ali ~/.config/git/config), ki je specifična za vsakega uporabnika. Do te datoteke lahko Git bere in piše z uporabo možnosti --global.

Nazadnje Git išče vrednosti konfiguracije v datoteki konfiguracije v direktoriju Git (.git/config) tega repozitorija, s katerim trenutno delate. Te vrednosti so specifične za ta posamezni repozitorij in predstavljajo podajanje možnosti --local pri git config. Če ne navedete, s katero ravnjo želite delati, je to privzeto.

Vsaka od teh »ravni« (sistem, globalno, lokalno) prepisuje vrednosti v prejšnji ravni, zato na primer vrednosti v .git/config prevladujejo nad tistimi v [path]/etc/gitconfig.

Note	Gitove konfiguracijske datoteke so navadne besedilne datoteke, zato lahko te vrednosti nastavite tudi z ročnim urejanjem datoteke in vstavljanjem pravilne sintakse. Vendar je običajno lažje uporabiti ukaz git config.

Osnovna konfiguracija odjemalca

Konfiguracijske možnosti, ki jih prepozna Git, se delijo na dve kategoriji: tiste na strani odjemalca in tiste na strani strežnika. Večina možnosti je namenjenih odjemalcu — konfiguriranju vaših osebnih delovnih nastavitev. Podprte so številne konfiguracijske možnosti, vendar je velik delež uporaben samo v določenih robnih primerih; tukaj bomo obravnavali le najpogostejše in najbolj uporabne možnosti. Če želite videti seznam vseh možnosti, ki jih prepozna vaša različica Gita, lahko zaženete:

$ man git-config

Ta ukaz izpiše vse možnosti, ki so na voljo, skupaj s podrobnostmi. Referenčno dokumentacijo najdete lahko tudi na https://git-scm.com/docs/git-config.

Note	Za naprednejše primere uporabe boste morda želeli pogledati »Conditional includes« v dokumentaciji zgoraj.

core.editor

Za ustvarjanje in urejanje vaših sporočil potrditev in oznak Git privzeto uporabi privzeti urejevalnik besedila, ki ste ga nastavili prek ene od spremenljivk okolja lupine VISUAL ali EDITOR, ali pa privzeto uporabi urejevalnik vi. Da spremenite privzeti urejevalnik na nekaj drugega, lahko uporabite nastavitev core.editor:

$ git config --global core.editor emacs

Sedaj, ne glede na to, kaj je nastavljeno kot privzeti urejevalnik lupine, bo Git zagnal Emacs za urejanje sporočil.

commit.template

Če to nastavite na pot do datoteke na svojem sistemu, bo Git to datoteko uporabil kot privzeto začetno sporočilo, ko izvedete potrditev. Prednost uporabe prilagojene predloge za potrditev je, da si s tem lahko pomagate, da se spomnite (ali da se drugi spomnijo) pravilne oblike in sloga pri ustvarjanju sporočila o potrditvi.

Na primer, razmislite o datoteki predloge na ~/.gitmessage.txt, ki je videti takole:

Subject line (try to keep under 50 characters)

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

[Ticket: X]

Opazite, kako ta predloga za potrditev spomni potrjevalca, naj obdrži kratko vrstico z naslovom (zaradi izhoda git log --oneline), da doda podrobnejše informacije pod tem naslovom in da se sklicuje na številko sledilnika težav ali napak, če ta obstaja.

Da Gitu poveste, naj ga uporabi kot privzeto sporočilo, ki se prikaže v vašem urejevalniku, ko zaženete git commit, nastavite vrednost konfiguracije commit.template:

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

Nato bo vaš urejevalnik odprl nekaj takega za vaše rezervirano mesto sporočila potrditve, ko potrdite:

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

Če ima vaša ekipa pravilnik za sporočila potrditev, potem lahko namestite predlogo za ta pravilnik na svoj sistem in nastavite Git, da ga privzeto uporablja, kar lahko pomaga povečati verjetnost, da se ta pravilnik redno upošteva.

core.pager

Ta nastavitev določa, katero številčenje strani se uporabi, ko Git prikazuje izpis, kot je log ali diff. Nastavite ga lahko na more ali na svoj najljubši pager (privzeto je less), lahko pa ga izklopite, tako da ga nastavite na prazen niz:

$ git config --global core.pager ''

Če to poženete, bo Git prikazoval izpis vseh ukazov po straneh, ne glede na to, kako so dolge.

user.signingkey

Če ustvarjate podpisane anotirane oznake (kot je opisano v razdelku ch07-git-tools.asc), nastavitev vašega ključa GPG kot konfiguracijske nastavitve olajša stvari. Nastavite svoj ID ključa na naslednji način:

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

Sedaj lahko podpišete oznake, brez da morate vsakič določiti vaš ključ z ukazom git tag:

$ git tag -s <tag-name>

core.excludesfile

V datoteko .gitignore vašega projekta lahko dodate vzorce, da Git teh datotek ne vidi kot nedodane ali da jih ne poskuša dodati v področje priprave, ko jih dodate z git add, kot je opisano v razdelku ch02-git-basics-chapter.asc.

Včasih pa želite prezreti določene datoteke za vse repozitorije, s katerimi delate. Če uporabljate računalnik z operacijskim sistemom macOS, verjetno poznate datoteke .DS_Store. Če je vaš priljubljeni urejevalnik Emacs ali Vim, poznate imena datotek, ki se končajo s ~ ali .swp.

Ta nastavitev vam omogoča pisanje neke vrste globalne datoteke .gitignore. Če ustvarite datoteko ~/.gitignore_global s to vsebino:

*~
.*.swp
.DS_Store

… in nato poženete git config --global core.excludesfile ~/.gitignore_global, vas Git ne bo več motil o teh datotekah.

help.autocorrect

Če napačno vpišete ukaz, vam bo pokazal nekaj takega:

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

The most similar command is
    checkout

Git poskuša ugotoviti, kaj ste mislili, vendar še vedno zavrne ukaz. Če nastavite help.autocorrect na 1, bo Git dejansko zagnal ta ukaz za vas:

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

Upoštevajte to stvar z »0,1 sekunde«. help.autocorrect je dejansko celo število, ki predstavlja desetinke sekunde. Če ga nastavite na 50, vam bo Git dal 5 sekund časa, da spremenite svoje mnenje, preden izvede samopopravljajoči se ukaz.

Barve v Gitu

Git popolnoma podpira obarvano terminalno izhodno sporočilo, kar močno pomaga pri vizualnem razčlenjevanju izhodov ukazov hitro in enostavno. Precej možnosti vam lahko pomaga nastaviti barvanje po željah.

color.ui

Git samodejno obarva večino svojega izhoda, vendar obstaja glavno stikalo, če vam ta funkcionalnost ni všeč. Če želite izklopiti vse barvne terminalne izhode Gita, to storite tako:

$ git config --global color.ui false

Privzeta nastavitev je auto, ki obarva izhod, ko gre neposredno v terminal, vendar izpusti nadzorne kode za barve, ko se izhod preusmeri v cev ali datoteko.

Lahko ga nastavite tudi na always, da prezrete razliko med terminali in cevmi. To boste redko želeli; v večini scenarijev, če želite barvne kode v svojem preusmerjenem izhodu, lahko namesto tega uporabite zastavico --color za ukaz Git, da ga prisilite k uporabi barvnih kod. Privzeta nastavitev je skoraj vedno tisto, kar želite.

color.*

Če želite biti bolj natančni glede tega, kateri ukazi so obarvani in kako, Git ponuja nastavitve barvanja, specifične za glagole. Vsako od teh lahko nastavite na true, false ali always:

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

Poleg tega ima vsaka od teh tudi podnastavitve, ki jih lahko uporabite za nastavitev posebnih barv za dele izhoda, če želite preglasiti vsako barvo. Na primer, da nastavite meta informacije v svojem diferenčnem izpisu na modro ozadje in krepko besedilo, lahko zaženete:

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

Barvo lahko nastavite na katero koli od naslednjih vrednosti: normal, black, red, green, yellow, blue, magenta, cyan, ali white. Če želite atribut, kot je krepko besedilo v prejšnjem primeru, lahko izbirate med bold, dim, ul (podčrtano), blink in reverse (zamenjava sprednjega in zadnjega zaslona).

Zunanja orodja za združevanja in razlike

Git ima vgrajeno implementacijo orodja diff, ki smo ga prikazovali v tej knjigi, vendar lahko namesto tega nastavite zunanje orodje. Namesto ročnega reševanja konfliktov lahko nastavite tudi grafično orodje za reševanje konfliktov. Pokazali bomo, kako nastaviti orodje za grafično združevanje in ločevanje datotek Perforce Visual Merge Tool (P4Merge), ker je lepo grafično orodje in je brezplačno.

Če želite to preizkusiti, lahko P4Merge uporabite na vseh glavnih platformah. V primerih bomo uporabljali imena poti, ki delujejo v sistemih macOS in Linux; za Windows boste morali spremeniti /usr/local/bin v izvršljivo pot v vašem okolju.

Najprej prenesite P4Merge iz Perforce. Nato boste nastavili zunanje vgradne skripte za zagon ukazov. V primeru uporabljamo pot macOS za izvršljiv program; v drugih sistemih bo tam, kjer je nameščena vaša binarna datoteka p4merge. Nastavite vgradni skript za združevanje z imenom extMerge, ki kliče vašo binarno datoteko z vsemi podanimi argumenti:

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

Ovojnica diff preveri, da je bilo zagotovljenih sedem argumentov in dva od njih prenese vaš združitveni skript. Git privzeto prenaša naslednje argumente programu diff:

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

Ker želite samo argumenta old-file in new-file, uporabite ovojni skript, da podate tiste, ki jih potrebujete.

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

Zagotoviti morate tudi, da so ta orodja izvršljiva:

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

Zdaj lahko nastavite konfiguracijsko datoteko, da uporablja vaše prilagojeno orodje za združevanje in orodja za razlike. To zahteva številne prilagojene nastavitve: merge.tool, da Gitu pove, katero strategijo naj uporabi, mergetool.<tool>.cmd, da določi, kako naj se ukaz izvede, mergetool.<tool>.trustExitCode, da pove Gitu, ali izhodna koda tega programa označuje uspešno združitev ali ne, in diff.external, da pove Gitu, kateri ukaz naj se uporabi za razlike. Tako lahko izvedete štiri ukazne konfiguracije:

$ 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

ali pa uredite vašo datoteko ~/.gitconfig, da dodate te vrstice:

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

Ko je vse to nastavljeno in če poženete ukaze diff, kot je:

$ git diff 32d1776b1^ 32d1776b1

Namesto da dobite izpis razlike v ukazni vrstici, bo Git zagnal P4Merge, ki je videti nekako takole:

Figure 1. P4Merge

Če poskušate združiti dve veji in imate nato konflikte med združevanjem, lahko za reševanje konfliktov uporabite ukaz git mergetool, ki začne program P4Merge in vam omogoča reševanje konfliktov preko grafičnega uporabniškega vmesnika tega orodja.

Lepa stvar pri tem sistemu ovijanja je, da lahko svoja orodja za primerjavo in združevanje preprosto spremenite. Na primer, če želite svoja orodja extDiff in extMerge zamenjati z orodjem KDiff3, morate le urediti svojo datoteko extMerge:

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

Git bo sedaj uporabljal orodje KDiff3 za prikazovanje razlik in razreševanje konfliktov združevanja.

Git je nastavljen tako, da uporablja vrsto drugih orodij za razreševanje združevanja, ne da bi morali nastaviti konfiguracijo cmd. Za ogled seznama podprtih orodij poskusite to:

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

Če vas ne zanima uporaba KDiff3 za primerjavo, ampak ga želite uporabiti le za razreševanje združitev in je kdiff3 ukaz v vaši poti, potem lahko zaženete:

$ git config --global merge.tool kdiff3

Če to izvedete namesto nastavljanja datotek extMerge in extDiff, bo Git za reševanje konfliktov uporabil KDiff3, za primerjavo pa normalno orodje za primerjavo Git.

Oblikovanje in prazni znaki

Oblikovne težave in težave praznih znakov so nekatere najbolj frustrirajočih in subtilnih težav, s katerimi se srečujejo številni razvijalci pri sodelovanju, še posebej če gre za sodelovanje na različnih platformah. Zelo lahko se zgodi, da oblika zapisa datoteke spreminja subtilne spremembe praznih znakov, saj urejevalniki teh sprememb ne oglašujejo in če se datoteke kdaj dotaknejo sistema Windows, se lahko spremenijo razmiki med vrsticami datotek. Git ima nekaj možnosti konfiguracije, ki pomagajo pri teh težavah.

core.autocrlf

Če programirate v operacijskem sistemu Windows in delate z ljudmi, ki tega ne uporabljajo (ali obratno), boste verjetno prej ali slej naleteli na težave z zaporedji konca vrstice. To je zato, ker Windows za nove vrstice v datotekah uporablja tako znak CR (angl. carriage return) kot tudi znak za prelom vrstice LF (angl. linefeed), medtem ko macOS in sistemi Linux uporabljajo samo znak za prelom vrstice LF. To je subtilen, a izjemno nadležen vidik dela na različnih platformah; mnogi urejevalniki na Windowsu tiho zamenjajo obstoječe LF-zaporedje konca vrstice s CRLF ali pa uporabniku pri pritisku na tipko enter vstavijo oba znaka zaporedja konca vrstice.

Git se s tem spopada tako, da samodejno pretvori zaporedja CRLF v LF, ko datoteko dodate v indeks, in obratno, ko izvleče kodo na vaš datotečni sistem. To funkcionalnost lahko vklopite s pomočjo nastavitve core.autocrlf. Če uporabljate računalnik z operacijskim sistemom Windows, ga nastavite na true — ta nastavitev pretvori LF v CRLF ob izvleku kode.

$ git config --global core.autocrlf true

Če delate na sistemu Linux ali macOS, ki uporablja konce vrstic LF, potem ne želite, da Git samodejno pretvarja konce vrstic, ko izvlečete datoteke; vendar, če se datoteka s konci CRLF nenamerno uvede, potem morda želite, da Git to popravi. Gitu lahko poveste, naj pretvori CRLF v LF ob potrditvi, vendar ne obratno, tako da nastavite core.autocrlf na input:

$ git config --global core.autocrlf input

Ta nastavitev bi morala pustiti konce CRLF v izvlekih kode na sistemu Windows, vendar konce LF v macOS in sistemih Linux ter v repozitoriju.

Če ste programer v okolju Windows in delate na projektu, ki je namenjen samo Windowsu, potem lahko to funkcionalnost zajemanja znakov CR v repozitoriju izklopite tako, da nastavitveno vrednost nastavite na false:

$ git config --global core.autocrlf false

core.whitespace

Git je privzeto nastavljen za odkrivanje in odpravljanje nekaterih težav s praznimi znaki. Lahko išče šest osnovnih težav s praznimi znaki — tri so privzeto omogočene in jih je mogoče izklopiti, tri pa so privzeto onemogočene, vendar jih je mogoče aktivirati.

Privzeto so omogočene tri: blank-at-eol, ki išče presledke na koncu vrstice; blank-at-eof, ki opazi prazne vrstice na koncu datoteke; in space-before-tab, ki išče presledke pred tabulatorji na začetku vrstice.

Tri, ki so privzeto onemogočene, jih je mogoče vklopiti: indent-with-non-tab, ki išče vrstice, ki se začnejo s presledki namesto tabulatorji (in ga nadzoruje možnost tabwidth); tab-in-indent, ki opazuje tabulatorje v delu zamika vrstice; in cr-at-eol, ki Gitu sporoči, da so na koncu vrstic sprejemljivi prehodi v novo vrstico znaki CR (angl. carriage return).

Gitu lahko sporočite, katere izmed teh možnosti želite omogočiti, tako da nastavite core.whitespace na vrednosti, ki jih želite vklopiti ali izklopiti, ločenimi z vejicami. Možnost lahko izklopite tako, da pred njenim imenom dodate -, ali pa uporabite privzeto vrednost tako, da jo pustite izven nastavitvene vrstice. Na primer, če želite nastaviti vse razen space-before-tab, lahko to storite tako (pri čemer je trailing-space bližnjica, ki zajema tako blank-at-eol kot tudi blank-at-eof):

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

Ali pa določite samo del prilagoditve:

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

Git bo zaznal te težave, ko zaženete ukaz git diff, in jih poskusil obarvati, tako da jih lahko morda popravite pred potrditvijo. Prav tako bo uporabil te vrednosti, da vam pomaga, ko uporabljate popravke z git apply. Ko uporabljate popravke, lahko Git zaprosite, naj vas opozori, ali uporablja popravke s posebnimi težavami s praznimi znaki z naslednjim ukazom:

$ git apply --whitespace=warn <patch>

Ali pa določite, da Git poskusi avtomatsko popraviti težavo preden uporabi programski popravek:

$ git apply --whitespace=fix <patch>

Te možnosti veljajo tudi za ukaz git rebase. Če ste zabeležili težave s praznimi znaki, vendar jih še niste potisnili navzgor, lahko za popravljanje samodejno uporabite git rebase --whitespace=fix, ko prepiše popravke.

Konfiguracija strežnika

Ni na voljo veliko konfiguracijskih možnosti za strežniško stran Gita, vendar obstaja nekaj zanimivih, na katere bi se morda želeli osredotočiti.

receive.fsckObjects

Git lahko poskrbi, da se vsak objekt, prejet med potiskanjem, še vedno ujema s svojo kontrolno vsoto SHA-1 in kaže na veljavne objekte. Vendar pa tega privzeto ne stori; to je precej draga operacija in lahko upočasni postopek, še posebej pri velikih repozitorijih ali potiskanjih. Če želite, da Git preveri skladnost objektov ob vsakem potiskanju, ga lahko prisilite, da to stori z nastavitvijo receive.fsckObjects na true:

$ git config --system receive.fsckObjects true

Zdaj bo Git preveril celovitost vašega repozitorija, preden sprejme kakršnokoli potiskanje, da se prepriča, da napačni (ali zlonamerni) odjemalci ne uvajajo pokvarjenih podatkov.

receive.denyNonFastForwards

Če boste ponovno bazirali že potisnjene potrditve in poskušali ponovno potisniti, ali poskušali potisniti potrditev na oddaljeno vejo, ki ne vsebuje potrditve, na katero trenutno kaže oddaljena veja, boste zavrnjeni. To je na splošno dobra praksa, vendar v primeru ponovnega baziranja morda veste, kaj počnete, in tako lahko prisilite posodobitev oddaljene veje z zastavico -f v ukazu potiskanja.

Da Gitu sporočite, naj zavrne prisilna potiskanja, nastavite receive.denyNonFastForwards:

$ git config --system receive.denyNonFastForwards true

Drug način, kako to storite, je prek prejemnih kljuk na strežniku, o čemer bomo podrobneje razpravljali malo kasneje. Ta pristop vam omogoča izvajanje bolj zapletenih ukazov, na primer zavračanje nehitrih previjanj naprej za določeno skupino uporabnikov.

receive.denyDeletes

Ena od nadomestnih rešitev za pravilnik denyNonFastForwards je, da uporabnik izbriše vejo in jo nato znova potisne z novo referenco. Da bi se temu izognili, nastavite receive.denyDeletes na true:

$ git config --system receive.denyDeletes true

To prepove vsako brisanje vej ali oznak — noben uporabnik tega ne more storiti. Za odstranitev oddaljenih vej morate datoteke ref na strežniku odstraniti ročno. Za to obstajajo tudi bolj zanimivi načini na uporabniški ravni prek ACL, kot se boste naučili v ch08-customizing-git.asc.