Chapters ▾ 2nd Edition

8.1 Customizing Git - Git Konfigurasie (Git Configuration)

So far, we’ve covered the basics of how Git works and how to use it, and we’ve introduced a number of tools that Git provides to help you use it easily and efficiently. In this chapter, we’ll see how you can make Git operate in a more customized fashion, by introducing several important configuration settings and the hooks system. With these tools, it’s easy to get Git to work exactly the way you, your company, or your group needs it to.

Git Konfigurasie (Git Configuration)

Soos jy kortliks gelees het in Aan die slag, kan jy Git-konfigurasie-instellings spesifiseer met die git config opdrag. Een van die eerste dinge wat jy gedoen het, was om jou naam en e-posadres op te stel:

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

Nou sal jy 'n paar van die meer interessante opsies leer wat jy op hierdie manier kan stel om jou Git-gebruik te pasmaak.

Eerstens, 'n vinnige oorsig: Git gebruik 'n reeks konfigurasielêers om nie-verstekgedrag te bepaal wat jy dalk verlang. Die eerste plek waar Git na hierdie waardes kyk, is in die stelselbreë [path]/etc/gitconfig lêer, wat instellings bevat wat toegepas word op elke gebruiker op die stelsel en al hul bewaarplekke. As jy die --system opsie na git config deursgee, lees en skryf dit spesifiek van hierdie lêer af.

Die volgende plek waar Git kyk, is die ~/.gitconfig (of ~/.config/git/config) lêer, wat spesifiek vir elke gebruiker is. Jy kan Git laat lees en skryf na hierdie lêer deur die --global opsie deur te gee.

Laastens kyk Git vir konfigurasiewarades in die konfigurasielêer in die Git-gids (.git/config) van watter bewaarplek jy ook al tans gebruik. Hierdie waardes is spesifiek vir daardie enkelvoudige bewaarplek, en verteenwoordig die deurgang van die --local opsie na git config. As jy nie spesifiseer met watter vlak jy wil werk nie, is dit die verstek.

Elkeen van hierdie “vlakke” (system, global, local) oorskryf waardes in die vorige vlak, sodat waardes in .git/config byvoorbeeld dié in [path]/etc/gitconfig troef.

Note

Git se konfigurasielêers is gewone tekslêers, so jy kan ook hierdie waardes stel deur die lêer handmatig te redigeer en die korrekte sintaksis in te voeg. Dit is oor die algemeen egter makliker om die git config opdrag uit te voer.

Basiese Kliëntkonfigurasie (Basic Client Configuration)

Die konfigurasie-opsies wat deur Git erken word, val in twee kategorieë: kliëntkant en bedienerkant. Die meerderheid van die opsies is kliëntkant – dit behels die konfigurasie van jou persoonlike werksvoorkeure. Baie, baie konfigurasie-opsies word ondersteun, maar 'n groot fraksie daarvan is slegs nuttig in sekere randgevalle; ons sal net die mees algemene en nuttige opsies hier dek. As jy 'n lys wil sien van al die opsies wat jou weergawe van Git erken, kan jy die volgende uitvoer:

$ man git-config

Hierdie opdrag lys al die beskikbare opsies met 'n redelike hoeveelheid detail. Jy kan ook hierdie verwysingsmateriaal vind by https://git-scm.com/docs/git-config.

Note

Vir gevorderde gebruiksgevalle wil jy dalk na "Conditional includes" soek in die dokumentasie wat hierbo genoem is.

core.editor

By verstek gebruik Git dit wat jy as jou standaard teksredigeerder gestel het via een van die dop-omgewingsveranderlikes (shell environment variables) VISUAL of EDITOR, of val anders terug op die vi redigeerder om jou vasleggings- en merkerboodskappe te skep en te redigeer. Om daardie verstek na iets anders te verander, kan jy die core.editor instelling gebruik:

$ git config --global core.editor emacs

Nou, ongeag wat as jou standaard dop-redigeerder gestel is, sal Git Emacs aanskakel om boodskappe te redigeer.

commit.template

As jy dit stel op die pad van 'n lêer op jou stelsel, sal Git daardie lêer as die verstek aanvanklijke boodskap gebruik wanneer jy vaslê (commit). Die waarde van die skep van 'n pasgemaakte vasleggingsjabloon is dat jy dit kan gebruik om jouself (of andere) te herinner aan die korrekte formaat en styl wanneer jy 'n vasleggingsboodskap skep.

Oorweeg byvoorbeeld 'n sjabloonlêer by ~/.gitmessage.txt wat so lyk:

Subject line (try to keep under 50 characters)

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

[Ticket: X]

Let op hoe hierdie vasleggingsjabloon die vaslêer herinner om die onderwerpregel kort te hou (ter wille van git log --oneline afvoer), om verdere detail daaronder by te voeg, en om na 'n kwessie- of foutopsporingkaartjienommer (ticket number) te verwys indien een bestaan.

Om vir Git te sê om dit te gebruik as die verstekboodskap wat in jou redigeerder verskyn wanneer jy git commit uitvoer, stel die commit.template konfigurasiewaarde:

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

Dan sal jou redigeerder oopmaak met iets soos dit vir jou duimplaasvasleggingsboodskap wanneer jy vaslê:

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

As jou span 'n beleid vir vasleggingsboodskappe het, dan kan die plasing van 'n sjabloon vir daardie beleid op jou stelsel en die konfigurasie van Git om dit by verstek te gebruik, help om die kans te verhoog dat daardie beleid gereeld gevolg word.

core.pager

Hierdie instelling bepaal watter blaaier (pager) gebruik word wanneer Git afvoer soos log and diff bladsy vir bladsy vertoon. Jy kan dit stel op more of jou gunsteling blaaier (by verstek is dit less), of jy kan dit afskakel deur dit op 'n leë string te stel:

$ git config --global core.pager ''

As jy dit uitvoer, sal Git die hele afvoer van alle opdragte druk, ongeag hoe lank dit is.

user.signingkey

As jy getekende geannoteerde merkers maak (soos bespreek in Ondertekening van Jou Werk (Signing Your Work)), maak die instelling van jou GPG-ondertekeningsleutel as 'n konfigurasie-instelling dinge makliker. Stel jou sleutel-ID soos volg in:

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

Nou kan jy merkers onderteken sonder om elke keer jou sleutel te hoef te spesifiseer met die git tag opdrag:

$ git tag -s <tag-name>

core.excludesfile

Jy kan patrone in jou projek se .gitignore lêer plaas sodat Git hulle nie beskou as onopgespoorde lêers of probeer om hulle voorberei (stage) wanneer jy git add daarop uitvoer nie, soos bespreek in Lêers ignoreer.

Maar soms wil jy sekere lêers vir alle bewaarplekke waarmee jy werk, ignoreer. As jou rekenaar macOS laat loop, is jy waarskynlik bekend met .DS_Store lêers. As jou voorkeurredigeerder Emacs of Vim is, ken jy lêername wat eindig op 'n ~ of .swp.

Hierdie instelling laat jou 'n soort globale .gitignore lêer skryf. As jy 'n ~/.gitignore_global lêer met hierdie inhoud skep:

*~
.*.swp
.DS_Store

…en jy voer git config --global core.excludesfile ~/.gitignore_global uit, sal Git jou nooit weer lastig val oor daardie lêers nie.

help.autocorrect

As jy 'n opdrag verkeerd tik, wys dit vir jou iets soos dit:

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

The most similar command is
    checkout

Git probeer behulpsaam uit te vind wat jy bedoel het, maar weier steeds om dit te doen. As jy help.autocorrect op 1 stel, sal Git eintlik hierdie opdrag vir jou uitvoer:

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

Let op daardie “0.1 sekondes” besigheid. help.autocorrect is eintlich 'n heelgetal (integer) wat tiendes van 'n sekonde verteenwoordig. Dus as jy dit op 50 stel, sal Git jou 5 sekondes gee om van gedagte te verander voordat die outokorrekte opdrag uitgevoer word.

Kleure in Git (Colors in Git)

Git ondersteun gekleurde terminaalafvoer ten volle, wat grootliks help om opdragafvoer vinnig en maklik visueel te ontleed. 'n Aantal opsies kan jou help om die kleuring na jou voorkeur te stel.

color.ui

Git kleur outomaties die meeste van sy afvoer, maar daar is 'n hoofskakelaar as jy nie van hierdie gedrag hou nie. Om al Git se gekleurde terminaalafvoer af te skakel, doen dit:

$ git config --global color.ui false

Die verstekinstelling is auto, wat afvoer kleur wanneer dit direk na 'n terminaal gaan, maar die kleurbeheerkodes weglat wanneer die afvoer na 'n pyp (pipe) of 'n lêer omgeleid word.

Jy kan dit ook stel op always om die verskil tussen terminale en pype te ignoreer. Jy sal dit selde wil hê; in die meeste scenario’s, as jy kleurkodes in jou omgeleide afvoer wil hê, kan jy in plaas daarvan 'n --color vlag na die Git-opdrag deursgee om dit te dwing om kleurkodes te gebruik. Die verstekinstelling is byna altyd dit wat jy sal wil hê.

color.*

As jy meer spesifiek wil wees oor watter opdragte gekleur word en hoe, bied Git werkwoordspesifieke kleurinstellings. Elkeen hiervan kan gestel word op true, false, of always:

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

Daarbenewens het elkeen hiervan subinstellings wat jy kan gebruik om spesifieke kleure vir dele van die afvoer te stel, as jy elke kleur wil oorskryf. Byvoorbeeld, om die metainligting in jou diff-afvoer te stel op blou voorgrond, swart agtergrond en vetgedrukte teks, kan jy die volgende uitvoer:

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

Jy kan die kleur stel op enige van die volgende waardes: normal, black, red, green, yellow, blue, magenta, cyan, of white. As jy 'n eienskap soos vetgedruk (bold) in die vorige voorbeeld wil hê, kan jy kies uit bold, dim, ul (onderstreep), blink, en reverse (omruil voor- en agtergrond).

Eksterne Samesmeltings- en Verskilgereedskap (External Merge and Diff Tools)

Alhoewel Git 'n interne implementering van diff het, wat is wat ons in hierdie boek gewys het, kan jy in plaas daarvan 'n eksterne hulpmiddel opstel. Jy kan ook 'n grafiese saamsmeltingskonflik-oplosmiddel opstel in plaas daarvan om konflikte handmatig te moet oplos. Ons sal die opstel van die Perforce Visual Merge Tool (P4Merge) demonstreer om jou diffs en saamsmeltingsresolusies te doen, omdat dit 'n oulike grafiese hulpmiddel is en dit gratis is.

As jy dit wil uitprobeer, P4Merge werk op alle groot platforms, so jy behoort dit te kan doen. Ons sal padname in die voorbeelde gebruik wat op macOS- en Linux-stelsels werk; vir Windows sal jy /usr/local/bin moet verander na 'n uitvoerbare pad in jou omgewing.

Om te begin, laai P4Merge af van Perforce. Volgende sal jy eksterne toedraai-skripte (wrapper scripts) opstel om jou opdragte uit te voer. Ons sal die macOS-pad vir die uitvoerbare lêer gebruik; in ander stelsels sal dit wees waar jou p4merge binêre lêer geïnstalleer is. Stel 'n samesmeltings-toedraaiskrip op genaamd extMerge wat jou binêre lêer met al die verskafde argumente aanroep:

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

Die diff-toedraaier kontroleer om seker te maak sewe argumente word verskaf en gee twee daarvan deur na jou samesmeltingsskrip. By verstek gee Git die volgende argumente deur na die diff-program:

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

Omdat jy slegs die old-file en new-file argumente wil hê, gebruik jy die toedraaiskrip om die talle deur te gee wat jy benodig.

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

Jy moet ook seker maak dat hierdie hulpmiddels uitvoerbaar is:

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

Nou kan jy jou konfigurasielêer opstel om jou pasgemaakte samesmeltingsresolusie- en diff-hulpmiddels te gebruik. Dit verg 'n aantal pasgemaakte instellings: merge.tool om vir Git te sê watter strategie om te gebruik, mergetool.<tool>.cmd om te spesifiseer hoe om die opdrag uit te voer, mergetool.<tool>.trustExitCode om vir Git te sê of die uitgangskode (exit code) van daardie program 'n suksesvolle samesmeltingsresolusie aangedui het al dan nie, en diff.external om vir Git te sê watter opdrag om vir diffs uit te voer. Dus kan jy of vier konfigurasie-opdragte uitvoer:

$ 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

of jy kan jou ~/.gitconfig lêer redigeer om hierdie reëls by te voeg:

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

Nadat al hierdie ingestel is, as jy diff-opdragte soos hierdie uitvoer:

$ git diff 32d1776b1^ 32d1776b1

In plaas daarvan om die diff-afvoer op die opdragreël te kry, skakel Git P4Merge aan, wat so iets lyk:

P4Merge
Figure 181. P4Merge

As jy probeer om twee takke aaneen te smelt en gevolgelyk saamsmeltingskonflikte het, kan jy die opdrag git mergetool uitvoer; dit begin P4Merge om jou in staat te stel om die konflikte deur daardie GUI-hulpmiddel op te los.

Die oulike ding van hierdie toedraai-opstelling is dat jy jou diff- en samesmeltingshulpmiddels maklik kan verander. Byvoorbeeld, om jou extDiff en extMerge hulpmiddels te verander om eerder die KDiff3 hulpmiddel uit te voer, hoef jy al wat te doen is net jou extMerge lêer te redigeer:

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

Nou sal Git die KDiff3 hulpmiddel gebruik vir diff-besigtiging en saamsmeltingskonflikoplossing.

Git kom vooraf ingestel om 'n aantal ander samesmeltingsresolusie-hulpmiddels te gebruik sonder dat jy die cmd-konfigurasie hoef op te stel. Om 'n lys te sien van die hulpmiddels wat dit ondersteun, probeer dit:

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

As jy nie belangstel om KDiff3 vir diff te gebruik nie, maar dit eerder net vir samesmeltingsresolusie wil gebruik, en die kdiff3 opdrag is in jou pad, dan kan jy uitvoer:

$ git config --global merge.tool kdiff3

As jy dit uitvoer in plaas daarvan om die extMerge en extDiff lêers op te stel, sal Git KDiff3 vir saamsmeltingsresolusie gebruik en die normale Git diff hulpmiddel vir diffs.

Formatering en Witruimte (Formatting and Whitespace)

Formatering en witruimtekwessies is van die mees frustrerende en subtiele probleme wat baie ontwikkelaars teëkom wanneer hulle saamwerk, veral kruisplatform (cross-platform). Dit is baie maklik vir pleisters (patches) of ander saamgewerkte werk om subtiele witruimteveranderings bekend te stel omdat redigeerders dit stilweg inbring, en as jou lêers ooit 'n Windows-stelsel aanraak, kan hul reëlyne vervang word. Git het 'n paar konfigurasie-opsies om met hierdie kwessies te help.

core.autocrlf

As jy op Windows programmeer en werk met mense wat dit nie doen nie (of omgekeerd), sal jy waarskynlik op 'n stadium met reëlynekwessies te kampe kry. Dit is omdat Windows sowel 'n wa-terugvoerkarakter (carriage-return) as 'n reëlvoerkarakter (linefeed) vir nuwe reëls in sy lêers gebruik, terwyl macOS- en Linux-stelsels slegs die reëlvoerkarakter gebruik. Dit is 'n subtiele maar ongelofelijk irriterende feit van kruisplatformwerk; baie redigeerders op Windows vervang stilweg bestaande LF-styl reëlyne met CRLF, of voeg beide reëlynekarakters in wanneer die gebruiker die enter-sleutel slaan.

Git kan dit hanteer deur CRLF-reëlyne outomaties in LF om te skakel wanneer jy 'n lêer by die indeks voeg, en omgekeerd wanneer dit kode na jou lêerstelsel uittrek. Jy kan hierdie funksionaliteit aanskakel met die core.autocrlf instelling. As jy op 'n Windows-masjien is, stel dit op true — dit skakel LF-eindpunte om na CRLF wanneer jy kode uittrek:

$ git config --global core.autocrlf true

As jy op 'n Linux- of macOS-stelsel is wat LF-reëlyne gebruik, dan wil jy nie hê dat Git hulle outomaties omskep wanneer jy lêers uittrek nie; egter, as 'n lêer met CRLF-eindpunte per ongeluk ingevoer word, wil jy dalk hê dat Git dit moet regmaak. Jy kan vir Git sê om CRLF na LF om te skakel met vaslegging (commit), maar nie andersom nie deur core.autocrlf op input te stel:

$ git config --global core.autocrlf input

Hierdie opstelling behoort jou te laat met CRLF-eindpunte in Windows-checkouts, maar LF-eindpunte op macOS- en Linux-stelsels en in die bewaarplek.

As jy 'n Windows-programmeerder is wat aan 'n projek slegs vir Windows werk, kan jy hierdie funksionaliteit afskakel, en die wa-terugvoerkarakters in die bewaarplek aanteken deur die konfigurasiewaarde op false te stel:

$ git config --global core.autocrlf false

core.whitespace

Git kom vooraf ingestel om sekere witruimtekwessies te detekteer en reg te maak. Dit kan kyk na ses primêre witruimtekwessies — drie word by verstek geaktiveer en kan afgeskakel word, en drie word by verstek gedeaktiveer maar kan geaktiveer word.

Die drie wat by verstek aangeskakel is, is blank-at-eol, wat kyk vir spasies aan die einde van 'n reël; blank-at-eof, wat leë reëls aan die einde van 'n lêer opmerk; en space-before-tab, wat kyk vir spasies voor tabs aan die begin van 'n reël.

Die drie wat by verstek gedeaktiveer is maar aangeskakel kan word, is indent-with-non-tab, wat kyk vir reëls wat begin met spasies in plaas van tabs (en word deur die tabwidth opsie beheers); tab-in-indent, wat waak vir tabs in die inspringingsgedeelte van 'n reël; en cr-at-eol, wat vir Git sê dat wa-terugvoere aan die einde van reëls OK is.

Jy kan vir Git sê watter van hierdie jy wil hê moet geaktiveer word deur core.whitespace te stel op die waardes wat jy aan of af wil hê, geskei deur kommas. Jy kan 'n opsie deaktiveer deur 'n - voor sy naam te plaas, of die verstekwaarde gebruik deur dit heeltemal uit die instellingstring weg te laat. Byvoorbeeld, as jy wil hê dat alles behalwe space-before-tab gestel moet word, kan jy dit so doen (met trailing-space as 'n kortskrif om beide blank-at-eol en blank-at-eof te dek):

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

Of jy kan slegs die pasmaakgedeelte spesifiseer:

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

Git sal hierdie kwessies detekteer wanneer jy 'n git diff opdrag uitvoer en probeer om hulle te kleur sodat jy dit moontlik kan regmaak voordat jy vaslê. Dit sal ook hierdie waardes gebruik om jou te help wanneer jy pleisters met git apply toepas. Wanneer jy pleisters toepas, kan jy vir Git vra om jou te waarsku as dit pleisters toepas met die gespesifiseerde witruimtekwessies:

$ git apply --whitespace=warn <patch>

Of jy kan hê dat Git probeer om die kwessie outomaties reg te maak voordat die pleister toegepas word:

$ git apply --whitespace=fix <patch>

Hierdie opsies is ook van toepassing op die git rebase opdrag. As jy witruimtekwessies vasgelê het maar nog nie stroomop gepush het nie, kan jy git rebase --whitespace=fix uitvoer sodat Git outomaties witruimtekwessies kan regmaak terwyl dit die pleisters herskryf.

Bedienerkonfigurasie (Server Configuration)

Nie annenaard so baie konfigurasie-opsies is beskikbaar vir die bedienerkant van Git nie, maar daar is 'n paar interessante waarvan jy dalk kennis wil neem.

receive.fsckObjects

Git is in staat om seker te maak dat elke objek wat tydens 'n push ontvang word, steeds ooreenstem met sy SHA-1 kontrolesom en na geldige objekte wys. Dit doen dit egter nie by verstek nie; dit is 'n redelik duur bewerking, en kan die bewerking vertraag, veral op groot bewaarplekke of pushes. Als jy wil hê dat Git objekkonsekwentheid op elke push moet kontroleer, kan jy dit dwing om dit te doen deur receive.fsckObjects op true te stel:

$ git config --system receive.fsckObjects true

Nou sal Git die integriteit van jou bewaarplek kontroleer voordat elke push aanvaar word om seker te maak dat foutiewe (of kwaadwillige) kliënte nie korrupte data inbring nie.

receive.denyNonFastForwards

As jy vasleggings rebased wat jy reeds gepusht het en dan weer probeer push, of andersins probeer om 'n vaslegging na 'n afgeleë tak te push wat nie die vaslegging bevat waarna die afgeleë tak tans wys nie, sal jy geweier word. Dit is oor die algemeen 'n goeie beleid; maar in die geval van die rebase, kan jy vasstel dat jy weet wat jy doen en die afgeleë tak geforceerd opdateer met 'n -f vlag vir jou push-opdrag.

Om vir Git te sê om geforceerde pushes te weier, stel receive.denyNonFastForwards:

$ git config --system receive.denyNonFastForwards true

Die ander manier waarop jy dit kan doen is via bedienerkant-ontvangshooks (receive hooks), wat ons binnekort sal dek. Daardie benadering laat jou toe om meer komplekse dinge te doen soos om nie-vinnige-voorwaartses (non-fast-forwards) aan 'n sekere subgroep gebruikers te weier.

receive.denyDeletes

Een van die omseilings van die denyNonFastForwards beleid is vir die gebruiker om die tak te verwyder en dit dan met die nuwe verwysing terug op te push. Om dit te vermy, stel receive.denyDeletes op true:

$ git config --system receive.denyDeletes true

Dit weier enige verwydering van takke of merkers — geen gebruiker kan dit doen nie. Om afgeleë takke te verwyder, moet jy die verwysingslêers (ref files) handmatig van die bediener af verwyder. Daar is ook meer interessante maniere om dit op 'n per-gebruiker-basis te doen via ACL’s, soos jy sal leer in 'n Voorbeeld van 'n Git-Afgedwonge Beleid (An Example Git-Enforced Policy).