Close

git config

In dit document gaan we uitgebreid in op de opdracht git config. We hebben het gebruik van git config kort besproken op onze pagina Een repository instellen. De opdracht git config is een gemaksfunctie die wordt gebruikt om Git-configuratiewaarden in te stellen op globaal of lokaal projectniveau. Deze configuratieniveaus komen overeen met .gitconfig-tekstbestanden. Wanneer git config wordt uitgevoerd, zal een tekstbestand met de configuratie worden aangepast. We behandelen algemene configuratie-instellingen, zoals e-mail, gebruikersnaam en editor. We bespreken ook Git-aliassen, waarmee je shortcuts kunt maken voor veelgebruikte Git-bewerkingen. Als je git config en de verschillende Git-configuratie-instellingen kent, kun je een krachtige, aangepaste Git-workflow creëren.


Gebruik


De meest eenvoudige toepassing van git config is het aanroepen ervan met een configuratienaam, waardoor de ingestelde waarde bij die naam wordt weergegeven. Configuratienamen zijn door punten gescheiden tekenreeksen die bestaan uit een 'sectie' en een 'sleutel' op basis van hun hiërarchie. Bijvoorbeeld: user.email

git config user.email

In dit voorbeeld is e-mail een onderliggende eigenschap van het gebruikersconfiguratieblok. Dit geeft het geconfigureerde e-mailadres weer, indien aanwezig, dat Git zal koppelen aan lokaal aangemaakte commits.

Niveaus en bestanden van git config

Voordat we verder over het gebruik van git config spreken, moeten we eerst even de configuratieniveaus bespreken. De opdracht git config kan argumenten accepteren om aan te geven op welk configuratieniveau moet worden gewerkt. De volgende configuratieniveaus zijn beschikbaar:

Git-branch
gerelateerd materiaal

Git-branch

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

  • --local

git config schrijft standaard naar een lokaal niveau als er geen configuratieoptie wordt doorgegeven. Configuratie op lokaal niveau wordt toegepast op de contextrepository waarin git config wordt aangeroepen. De waarden van de lokale configuratie worden opgeslagen in een bestand dat te vinden is in de .git-map van de repo .git/config

  • --global

De configuratie op globaal niveau is gebruikerspecifiek, wat betekent dat de configuratie wordt toegepast op een gebruiker van het besturingssysteem. Algemene configuratiewaarden worden opgeslagen in een bestand dat zich in de persoonlijke map van een gebruiker bevindt. ~/.gitconfig op Unix-systemen en C:\Users\\.gitconfig op Windows

  • --system

Configuratie op systeemniveau wordt toegepast op de hele machine. Dit geldt voor alle gebruikers van een besturingssysteem en alle repo's. Het configuratiebestand op systeemniveau bevindt zich in een gitconfig-bestand buiten het hoofdpad van het systeem. $(prefix)/etc/gitconfig op unix-systemen. In Windows is dit bestand te vinden in C:\Documents and Settings\All Users\Application Data\Git\config op Windows XP en in C:\ProgramData\Git\config op Windows Vista en nieuwere versies.

De volgorde van prioriteit voor configuratieniveaus is dus: lokaal, globaal, systeem. Dit betekent dat als je naar een configuratiewaarde zoekt, Git op lokaal niveau wordt gestart en naar het systeemniveau gaat.

Een waarde schrijven

Laten we, om verder te borduren op wat we al weten over git config, een voorbeeld bekijken waarin we een waarde schrijven:

git config --global user.email "your_email@example.com"

In dit voorbeeld wordt de waarde jouw_e-mail@voorbeeld.com naar de configuratienaam user.email geschreven. Er wordt de markering --global gebruikt, zodat deze waarde wordt ingesteld voor de huidige gebruiker van het besturingssysteem.

git config-editor - core.editor


Bij veel Git-opdrachten wordt een teksteditor gestart om verdere invoer te vragen. Een van de meest voorkomende gevallen waarin git config wordt gebruikt, is om te configureren welke editor Git moet gebruiken. Hieronder staat een tabel met populaire editors en bijbehorende git config-opdrachten:

Editor

config-opdracht

Atom

config-opdracht

~ git config --global core.editor "atom --wait"~

emacs

config-opdracht

~ git config --global core.editor "emacs"~

nano

config-opdracht

~ git config --global core.editor "nano -w"~

vim

config-opdracht

~ git config --global core.editor "vim"~

Sublime Text (Mac)

config-opdracht

~ git config --global core.editor "subl -n -w"~

Sublime Text (Win, 32-bits-installatie)

config-opdracht

~ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublimetext.exe' -w"~

Sublime Text (Win, 64-bits-installatie)

config-opdracht

~ git config --global core.editor "'c:/program files/sublime text 3/sublimetext.exe' -w"~

Textmate

config-opdracht

~ git config --global core.editor "mate -w"~

Samenvoegingstools


In het geval van een samenvoegingsconflict zal Git een 'samenvoegingstool' openen. Git gebruikt standaard een interne implementatie van het algemene Unix diff-programma. Het interne Git diff is een minimalistisch weergaveprogramma voor samenvoeging van conflicten. In plaats daarvan zijn er veel externe oplossingen voor samenvoeging van conflicten die kunnen worden gebruikt. Een overzicht van verschillende samenvoegingstools en configuraties vind je in onze gids met tips en tools om conflicten met Git op te lossen.

git config --global merge.tool kdiff3

Gekleurde uitvoer


Git ondersteunt gekleurde terminaluitvoer, wat helpt bij het snel lezen van Git-uitvoer. Je kunt je Git-uitvoer aanpassen om een gepersonaliseerd kleurenthema te gebruiken. De git config-opdracht wordt gebruikt om deze kleurwaarden in te stellen.

color.ui

Dit is de hoofdvariabele voor Git-kleuren. Als je deze op 'false' instelt, wordt alle gekleurde terminaluitvoer van Git uitgeschakeld.

$ git config --global color.ui false

color.ui is standaard ingesteld op automatisch, waardoor kleuren worden toegepast op de directe uitvoerstream van de terminal. Bij de automatische instelling wordt de kleurcode-uitvoer achterwege gelaten als de uitvoerstream wordt omgeleid naar een bestand of naar een ander proces wordt geleid.

Je kunt de waarde color.ui instellen op 'always', wat ook van toepassing is op kleurcode-uitvoer wanneer de uitvoerstream wordt omgeleid naar bestanden of pipes. Dit kan onbedoeld problemen veroorzaken, aangezien de ontvangende pipe mogelijk geen invoer met kleurcodering verwacht.

Git-kleurwaarden

Naast color.ui zijn er veel andere granulaire kleurinstellingen. Net als in color.ui kunnen deze kleurinstellingen allemaal worden ingesteld op 'false', 'auto' of 'always'. Bij deze kleurinstellingen kan ook een specifieke kleurwaarde worden ingesteld. Enkele voorbeelden van ondersteunde kleurwaarden zijn:

  • Normaal
  • Zwart
  • rood
  • groen
  • geel
  • blauw
  • magenta
  • cyan
  • Schrijven

Kleuren kunnen ook worden gespecificeerd als hexadecimale kleurcodes, zoals #ff0000, of ANSI 256-kleurwaarden als je terminal dit ondersteunt.

Configuratie-instellingen voor Git-kleuren

1. color.branch

  • Configureert de uitvoerkleur van de Git-branch-opdracht

2. color.branch.<slot>

  • Deze waarde is ook van toepassing op de uitvoer van de Git-branch. <slot> heeft een van de volgende waarden:
    • 1. current: de huidige branch
    • 2. local: een lokale branch
    • 3. remote: een verwijzing naar een branch in refs/remotes
    • 4. upstream: een stroomopwaartse branch die wordt gevolgd
    • 5. plain: elke andere ref

3. color.diff

  • Past kleuren toe op git diff-, git log- en git show-uitvoer

4. color.diff.<slot>

  • Als je een -waarde onder color.diff configureert, vertelt Git voor welk deel van de patch een specifieke kleur moet worden gebruikt.
    • 1. context: de contexttekst van het diff. Git-context bestaat uit de tekstinhoud die wordt weergegeven in een diff of patch waarin wijzigingen worden gemarkeerd.
    • 2. plain: een synoniem voor context
    • 3. meta: past kleur toe op de meta-informatie van de diff
    • 4. frag: past kleur toe op de 'hunk header' of 'functie in hunk header'
    • 5. old: past een kleur toe op de verwijderde regels in het diff
    • 6. new: geeft kleur aan de toegevoegde regels in het diff
    • 7. commit: geeft kleur aan commit-headers in het diff
    • 8. whitespace: stelt een kleur in voor eventuele witruimtefouten in een diff

5. color.decorate.<slot>

  • Pas de kleur aan voor de uitvoer van git log --decorate. De ondersteunde <slot>-waarden zijn: branch, remoteBranch, tag, stash en HEAD. Ze zijn respectievelijk van toepassing op lokale branches, remote tracking-branches, tags, verborgen wijzigingen en HEAD.

6. color.grep

  • Past kleur toe op de uitvoer van git grep.

7. color.grep. <slot>

  • Ook van toepassing op git grep. De <slot>-variabele geeft aan op welk deel van de grep-uitvoer de kleur moet worden toegepast.
    • 1. context: tekst die niet overeenkomt in contextregels
    • 2. filename: voorvoegsel voor bestandsnaam
    • 3. function: naamregels van de functie
    • 4. linenumber: voorvoegsel voor regelnummers
    • 5. match: overeenkomende tekst
    • 6. matchContext: overeenkomende tekst in contextregels
    • 7. MatchSelected: overeenkomende tekst in geselecteerde regels
    • 8. selected: tekst komt niet overeen in geselecteerde regels
    • 9. separator: scheidingstekens tussen velden op een regel (:, - en =) en tussen hunks (--)

8. color.interactive

  • Deze variabele is van toepassing op kleuren voor interactieve prompts en displays. Voorbeelden zijn git add --interactive en git clean --interactive

9. color.interactive.<slot>

  • De <slot>-variabele kan worden gespecificeerd voor een specifiekere 'interactieve output'. De beschikbare <slot>-waarden zijn: prompt, header, help, error. Elk beïnvloedt de bijbehorende interactieve uitvoer.

10. color.pager

  • Schakelt gekleurde uitvoer in of uit wanneer de pager in gebruik is

11. color.showBranch

  • Schakelt de kleuruitvoer in of uit voor de opdracht git show branch

12. color.status

  • Een booleaanse waarde die de kleuruitvoer voor de Git-status in- of uitschakelt

13. color.status.<slot>

Wordt gebruikt om een aangepaste kleur op te geven voor specifieke git status-elementen. <slot> ondersteunt de volgende waarden:

1. header

  • Richt zich op de koptekst van het statusgebied

2. added of updated

  • Beide zijn gericht op bestanden die zijn toegevoegd maar waarvoor geen commits zijn gemaakt

3. changed

  • Beïnvloedt bestanden die zijn gewijzigd maar die niet aan de Git-index zijn toegevoegd

4. untracked

  • Beïnvloedt bestanden die niet door Git worden bijgehouden

5. branch

  • Past kleur toe op de huidige branch

6. nobranch

  • De kleur waarin de waarschuwing 'no branch' wordt weergegeven

7. unmerged

  • Kleurt bestanden met niet-samengevoegde wijzigingen

Aliassen


Je bent misschien bekend met het concept van aliassen in de opdrachtregel van je besturingssysteem. Dat zijn het aangepaste sortcuts die bepalen welke opdracht wordt uitgebreid naar langere of gecombineerde opdrachten. Aliassen besparen tijd en energie bij het typen van veelgebruikte opdrachten. Git biedt zijn eigen aliassysteem. Git-aliassen worden vaak gebruikt om de commit-opdracht in te korten. Git-aliassen worden opgeslagen in Git-configuratiebestanden. Dit betekent dat je de git config-opdracht kunt gebruiken om aliassen te configureren.

git config --global alias.ci commit

In dit voorbeeld wordt een CI-alias aangemaakt voor de opdracht git commit. Je kunt dan git commit aanroepen door git ci uit te voeren. Aliassen kunnen ook naar andere aliassen verwijzen en krachtige combinaties vormen.

git config --global alias.amend ci --amend

In dit voorbeeld wordt een alias aangemaakt, waarbij de ci-alias wordt samengesteld tot een nieuwe alias die de markering --amend gebruikt.

Opmaak en witruimte


Git heeft verschillende functies voor 'witruimte' die kunnen worden geconfigureerd om problemen met de witruimte te signaleren bij het gebruik van git diff. De problemen met de witruimte worden gemarkeerd met de geconfigureerde color.diff.whitespace

De volgende functies zijn standaard ingeschakeld:

  • blank-at-eol markeert lege witruimtes aan de regeleinden
  • space-before-tab markeert een spatie vóór een tab bij het inspringen van een regel
  • blank-at-eof markeert lege regels die aan het einde van een bestand zijn ingevoegd

De volgende functies zijn standaard uitgeschakeld

  • indent-with-non-tab markeert een regel die is ingesprongen met spaties in plaats van tabs
  • tab-in-indent markeert een eerste tab-inspringing als een fout
  • trailing-space is een afkorting voor zowel blank-at-eol als blank-at-eof
  • cr-at-eol highlights voortzetting van een lange zin op een nieuwe regel
  • tabwidth= bepaalt hoeveel tekens een tab inneemt. De standaardwaarde is 8. Waarden tussen 1 en 63 zijn toegestaan

Samenvatting


In dit artikel hebben we het gebruik van de git config-opdracht besproken. We hebben besproken hoe de opdracht een overtuigende methode is voor het bewerken van onbewerkte git config-bestanden in het bestandssysteem. We hebben gekeken naar eenvoudige lees- en schrijfbewerkingen voor configuratieopties. We hebben algemene configuratiepatronen bekeken:

  • De Git-editor configureren
  • Configuratieniveaus overschrijven
  • Standaard configuratie-instellingen opnieuw instellen
  • Git-kleuren aanpassen

In het algemeen is git config een hulpmiddel waarmee je snel onbewerkte git config-bestanden op de schijf kunt bewerken. We hebben uitgebreide aanpassingsmogelijkheden besproken. Basiskennis van de configuratieopties voor Git is een vereiste voor het opzetten van een repository. Zie onze gids daar voor een demonstratie van de basisbeginselen.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up