8.1 Git aanpassen - Git configuratie

Standaard gebruikt Git hetgeen je hebt ingesteld als je standaard tekstverwerker ($VISUAL of $EDITOR) en anders valt het terug op de vi tekstverwerker om jouw commit en tag berichten te maken en te onderhouden. Om deze standaard naar iets anders te verandereen, kan je de core.editor instelling gebruiken:

Nu maakt het niet meer uit wat je standaard shell editor is, Git zal Emacs opstarten om je berichten te wijzigen.

Als je dit instelt op het pad van een bestand op je systeem, zal Git dat bestand gebruiken als het standaard bericht als je commit. De waarde van het maken van een standaard bericht voorbeeld is dat je dit kan gebruiken om jezelf (of anderen) eraan kan herinneren om de juiste formattering en stijl te gebruiken voor het maken van een commit-bericht.

Bijvoorbeeld, stel dat je een sjabloon bestand op ~/.gitmessage.txt hebt gemaakt dat er zo uitziet:

Zie hoe dit sjabloon de committer eraan herinnert om de onderwerpregel kort te houden (ten behoeve van de git log --oneline-uitvoer), verdere details eronder te vermelden en om naar een issue of bug-tracker systeem (mocht die bestaan) referentie te verwijzen.

Om Git te vertellen dat het dit als het standaard bericht moet gebruiken dat in je tekstverwerker verschijnt als je git commit aanroept, zet dan de commit.template configuratie waarde:

Dan zal je tekstverwerker het volgende als je commit bericht sjabloon gebruiken als je gaat committen:

Als je team een commit-bericht voorschrift heeft, dan zal het inrichten van een sjabloon voor dat voorschrift op jouw systeem en het inrichten van Git om dit standaard te gebruiken helpen met het vergroten van de kans dat dat voorschrift ook daadwerkelijk wordt opgevolgd.

Het instellen van deze waarde bepaalt welke pagineerhulp wordt gebruikt als Git uitvoer als log en diff gaat pagineren. Je kunt dit op more of jouw favoriete pagineerhulp instellen (standaard is het less), of je kunt het uitzetten door een lege waarde te geven:

Als je dat aanroept, zal Git de gehele uitvoer van alle commando’s tonen, onafhankelijk van de lengte van deze uitvoer.

Als je getekende geannoteerde tags aanmaakt (zoals behandeld in Je werk tekenen), zal het inrichten van je GPG handtekening als configuratie setting dingen eenvoudiger maken. Stel jouw sleutel ID als volgt in:

Nu kan je tags tekenen zonder elke keer je sleutel op te hoeven geven als je het git tag commando aanroept:

Je kunt patronen in het .gitignore bestand van je project zetten om Git deze niet als untracked bestanden te laten beschouwen of deze zal proberen te stagen als je git add op ze aanroept, zoals beschreven in Bestanden negeren.

Maar soms wil je bepaalde bestanden negeren voor alle repositories waar je in werkt. Als je computer onder macOS draait, ben je waarschijnlijk bekend met .DS_Store bestanden. Als je voorkeurs-tekstverwerker Emacs of Vim is, zullen bestanden die eindigen op een ~ of .swp je bekend voorkomen.

Deze instelling laat je een soort globale .gitingore bestand aanmaken. Als je een ~/.gitignore_global bestand aanmaakt met deze inhoud:

…​en je roept git config --global core.excludesfile ~/.gitignore_global aan, zal Git je nooit meer lastig vallen over deze bestanden.

Als je een typefout maakt in een commando, laat het je iets als dit zien:

Git probeert behulpzaam uit te vinden wat je bedoeld zou kunnen hebben, maar weigert het wel dit uit te voeren. Als je help.autocorrect op 1 instelt, zal Git het commando daadwerkelijk voor je uitvoeren:

Merk het “0.1 seconden” gedoe op. help.autocorrect is eigenlijk een integer waarde die tienden van een seconde vertegenwoordigt. Dus als je het op 50 zet, zal Git je 5 seconden geven om van gedachten te veranderen voordat het automatisch gecorrigeerde commando wordt uitgevoerd.

Git geeft automatisch de meeste van haar uitvoer in kleur weer, maar er is een hoofdschakelaar als dit gedrag je niet bevalt. Om alle kleuren uitvoer van Git uit te zetten, voer je dit uit:

De standaard waarde is auto, wat de uitvoer kleur geeft als het direct naar een terminal wordt gestuurd, maar laat de kleuren-stuurcodes achterwege als de uitvoer naar een pipe of een bestand wordt omgeleid.

Je kunt het ook instellen op always om het onderscheid tussen terminals en pipes te negeren. Je zult dit zelden willen in de meeste gevallen, als je kleuren-stuurcodes in je omgeleide uitvoer wilt, kan je in plaats daarvan een --color vlag aan het Git commando doorgeven om het te dwingen om kleurcodes te gebruiken. De standaard instelling is vrijwel altijd hetgeen je zult willen.

Als je meer controle wilt hebben over welke commando’s gekleurd worden en hoe, heeft Git argument-specifieke kleuren-instellingen. Elk van deze kan worden gezet op true, false of always:

Daarenboven heeft elk van deze specifiekere instellingen die je kunt gebruiken om specifieke kleuren voor delen van de uitvoer te bepalen, als je elke kleur zou willen herbepalen. Bijvoorbeeld, om de meta-informatie in je diff uitvoer op een blauwe voorgrond, zwarte achtergrond en vetgedrukte tekst in te stellen, kan je het volgende uitvoeren:

Je kunt de kleur instellen op elk van de volgende waarden: normal, black, red, green, yellow, blue, magenta, cyan, of white. Als je een attribuut als vetgedrukt (bold) in het vorige voorbeeld wilt, kan je kiezen uit bold, dim (minder helder), ul (onderstrepen, underline), blink (knipperen), en reverse (verwissel voor- en achtergrond).

Als je in Windows programmeert en werkt met mensen die dat niet doen (of vice-versa), zal je waarschijnlijk op enig moment met regel-einde problematiek te maken krijgen. Dit is omdat Windows zowel een wagen-terugvoer teken (carriage-return) en een regelopvoer teken (linefeed) gebruikt voor nieuwe regels in haar bestanden, waar macOS en Linux systemen alleen het linefeed teken gebruiken. Dit is een subtiel maar ongelofelijk ergerlijk feit van het werken op verschillende platforms; veel tekstverwerkers op Windows vervangen stilletjes bestaande LF-stijl regeleinden met CRLF, of voegen beide regel-einde karakters in als de gebruiker de enter toets gebruikt.

Git kan dit verwerken door automatisch CRLF regel-einden te converteren in een LF als je een bestand in de index toevoegt, en vice-versa als je code uitcheckt naar je bestandssysteem. Je kunt deze functionaliteit aanzetten met de core.autocrlf instelling. Als je op een Windows machine werkt, zet dit dan op true - dit zal LF einden naar CRLF vertalen als je code uitcheckt:

Als je op een Linux of macOS systeem werkt die LF regeleinden gebruikt, dan wil je niet dat Git deze automatisch vertaalt als je bestanden uitcheckt, echter als een bestand met CRLF regeleinden per ongeluk binnenkomt, dan zou je wellicht willen dat Git dit rechttrekt. Je kunt Git vertellen om CRLF naar LF te vertalen bij een commit, maar niet omgekeerd door de instelling core.autocrlf op input te zetten:

Met deze instelling zou je uit moeten komen met CRLF regeleinden in Windows checkouts, maar LF regeleinden op macOS en Linux systemen en in de repository.

Als je een Windows programmeur bent die aan een project werkt voor alleen Windows, kan je deze functionaliteit uitzetten, waarbij carriage returns in de repository worden vastgelegd door de configuratie waarde op false te zetten:

Git wordt geleverd met de instelling om een aantal witruimte problemen te detecteren en op te lossen. Het kan zoeken naar zes meestvoorkomende witruimte problemen — drie ervan zijn standaard ingeschakeld en kunnen worden uitgeschakeld, en drie zijn uitgeschakeld maar kunnen worden geactiveerd.

Degenen die standaard aanstaan zijn blank-at-eol, die naar spaties aan het eind van een regel kijkt; blank-at-eof, die blanco regels opmerkt aan het eind van een bestand; en space-before-tab, die kijkt naar spaties voor tabs aan het begin van een regel.

De drie die standaard uitstaan, maar die kunnen worden aangezet, zijn indent-with-non-tab, die kijkt naar regels die beginnen met spaties in plaats van tabs (en wordt geregeld met de tabwidth optie); tab-in-indent, die kijkt naar tabs in het inspring-gedeelte van een regel; en cr-at-eol, welke Git vertelt dat carriage returns aan het eind van regels worden geaccepteerd.

Je kunt Git vertellen welke van deze je ingeschakeld wilt hebben door core.whitespace op de waarden te zetten die je aan of uit wilt hebben, gescheiden met komma’s. Je kunt instellingen uitzetten door ze weg te laten uit de instelling-reeks of ze vooraf te laten gaan met een -. Bijvoorbeeld, als je alles behalve cr-at-eol wilt inschakelen kan je dit doen (met trailing-space als afkorting die zowel blank-at-eol als `blank-at-eof`afdekt):

Of je kunt alleen het specificerende gedeelte aangeven:

Git zal deze problemen opsporen als je een git diff commando aanroept en ze proberen met een kleur aan te geven zodat je ze mogelijk kunt oplossen voordat je commit. Het zal deze waarden ook gebruiken om je te helpen als je patches toepast met git apply. Als je patches aan het toepassen bent, kan je Git ook vragen om je te waarschuwen als het patches toepast met de aangegeven witruimte problematiek:

Of je kunt Git het probleem automatisch laten proberen op te lossen voordat het de patch toepast:

Deze opties zijn ook van toepassing voor het git rebase commando. Als je witruimte problemen hebt gecommit, maar je hebt ze nog niet stroomopwaarts gepusht, kan je git rebase --whitespace=fix aanroepen om Git deze problemen automatisch te laten oplossen als het de patches herschrijft.

Git is in staat om te verifiëren dat elk ontvangen object bij een push nog steeds een passende SHA-1 checksum heeft en naar geldige objecten wijst. Dit doet het echter niet standaard; het is een relatief dure operatie, en kan het uitvoeren van de operatie vertragen, zeker bij grote repositories of pushes. Als je wilt dat Git object consistentie bij elke push controleert, kan je dit afdwingen door receive.fsckObjects op true te zetten:

Nu zal Git de integriteit van je repository controleren voordat elke push wordt geaccepteerd om er zeker van te zijn dat defecte (of kwaadwillende) werkstations geen corrupte gegevens aanleveren.

Als je commits rebased die je al gepusht hebt en dan weer probeert te pushen, of op een andere manier probeert eencommit te pushen naar een remote branch die de commit niet bevat waar de remote branch op dit moment naar wijst, zal dit geweigerd worden. Dit is normaalgesproken een goed beleid, maar in het geval van de rebase, kan je besluiten dat je weet wat je aan het doen bent en de remote branch geforceerd updaten met een -f vlag bij je push commando.

Om Git te vertellen om geforceerd pushen te weigeren, zet je receive.denyNonFastForwards:

De andere manier waarop je dit kunt doen is via receive hooks aan de kant van de server, waar we straks meer over gaan vertellen. Die aanpak stelt je ook in staat om iets complexere dingen te doen als het weigeren van non-fast-forwards bij een bepaalde groep van gebruikers.

Een van de manieren om om het denyNonFastForwards beleid heen te werken is om als gebruiker de branch te verwijderen en deze dan weer te pushen met de nieuwe referenties. Om dit te voorkomen, zet receive.denyDeletes op true:

Dit weigert het verwijderen van branches of tags — geen enkele gebruiker kan dit doen. Om remote branches te verwijderen, moet je de ref-bestanden handmatig van de server verwijderen. Er zijn nog meer interessante manieren om dit te doen op een gebruikersgerichte manier via ACL’s, zoals je zult zien in Een voorbeeld van Git-afgedwongen beleid.