8.1 Prilagoditev Gita - Konfiguracija Git

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:

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

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

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:

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

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

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:

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

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

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

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 Ignoriranje datotek.

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:

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

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

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:

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.

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:

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.

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

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:

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

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

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

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

Ali pa določite samo del prilagoditve:

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:

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

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.

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:

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.

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

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.

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:

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 Primer pravilnika, ki ga uveljavlja Git.