Svenska ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.54.0

NAMN

git-checkout - Byt gren eller återställ filer i arbetsträdet

SYNOPSIS

git checkout [-q] [-f] [-m] [<gren>]
git checkout [-q] [-f] [-m] --detach [<gren>]
git checkout [-q] [-f] [-m] [--detach] <incheckning>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <ny-grel>] [<start-punkt>]
git checkout <tree-ish> [--] <sökvägsspec>…​
git checkout <tree-ish> --pathspec-from-file=<fil> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] [--] <sökvägsmönster>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<trädlikt>] [--] [<sökvägsspec>…​]

BESKRIVNING

git checkout har två huvudlägen:

  1. Byt grenar, med git checkout <gren>

  2. Återställ en annan version av en fil, till exempel med git checkout <incheckning> <filnamn> eller git checkout <filnamn>

Se ARGUMENT SÄRSKILJNING nedan för hur Git bestämmer vilken som ska göras.

git checkout [<gren>]

Växla till <gren>. Detta ställer in den aktuella grenen till <gren> och uppdaterar filerna i din arbetskatalog. Utcheckningen kommer att misslyckas om det finns oincheckade ändringar i filer där <gren> och din nuvarande incheckning har olika innehåll. Oincheckade ändringar kommer annars att behållas.

Om <gren> inte hittas men det finns en spårningsgren i exakt en fjärr (kalla den <fjärr>) med ett matchande namn och --no-guess inte är specificerat, behandla den som likvärdig med

$ git checkout -b <gren> --track <fjärr>/<gren>

Att köra git checkout utan att ange en gren har ingen effekt förutom att skriva ut spårningsinformationen för den aktuella grenen.

git checkout -b <ny-gren> [<start-punkt>]

Skapa en ny gren med namnet <ny-gren>, starta den vid <start-punkt> (standardinställningen är den nuvarande incheckningen) och checka ut den nya grenen. Du kan använda alternativen --track eller --no-track för att ställa in grenens uppströms spårningsinformation.

Det kommer att misslyckas om det uppstår ett fel vid utcheckning av <ny-gren>, till exempel om utcheckning av <start-punkt>-incheckningen skulle skriva över oincheckade ändringar.

git checkout -B <gren> [<start-punkt>]

Samma som -b, förutom att om grenen redan finns återställer den <gren> till startpunkten i stället för att misslyckas.

git checkout --detach [<gren>]
git checkout [--detach] <incheckning>

Samma som git checkout <gren>, förutom att den i stället för att peka HEAD mot grenen pekar HEAD mot inchecknings-ID:t. Se avsnittet "FRÅNKOPPLAT HEAD" nedan för mer information.

Om man utelämnar <gren> lossnar HEAD i toppen av den aktuella grenen.

git checkout <trädlikt> [--] <sökvägsmönster>...
git checkout <trädlikt> --pathspec-from-file=<fil> [--pathspec-file-nul]

Ersätt de angivna filerna och/eller katalogerna med versionen från den givna incheckningen eller trädet och lägg till dem i indexet (även känt som "prepareringsytan").

Till exempel, kommer git checkout main file.txt att ersätta file.txt med versionen från main.

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <sökvägsmönster>...
git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] --pathspec-from-file=<file> [--pathspec-file-nul]

Ersätt de angivna filerna och/eller katalogerna med versionen från indexet.

Om du till exempel checkar ut en incheckning, redigerar file.txt och sedan bestämmer dig för att ändringarna var ett misstag, kommer git checkout file.txt att ignorera alla ej köade ändringar av file.txt.

Det kommer att misslyckas om filen har en sammanslagningskonflikt och ännu inte har kört git add file.txt (eller något motsvarande) för att markera den som löst. -f kan användas för att ignorera de icke-sammanslagna filerna i stället för att misslyckas, använda --ours eller --theirs för att ersätta dem med versionen från en specifik sida av sammanslagningen, eller använda -m för att ersätta dem med det ursprungliga konfliktfyllda sammanslagningsresultatet.

git checkout (-p|--patch) [<trädlikt>] [--] [<sökvägsmönster>...]

Det liknar de två föregående lägena, men gör det möjligt att använda det interaktiva gränssnittet för att visa "diff"-utdata och välja vilka stycken som ska användas i resultatet. Se nedan för beskrivningen av alternativet --patch.

ALTERNATIV

-q
--quiet

Tyst, undertryck feedbackmeddelanden.

--progress
--no-progress

Förloppsstatus rapporteras som standard i standardfelströmmen när den är ansluten till en terminal, såvida inte --quiet anges. Denna flagga aktiverar förloppsrapportering även om den inte är ansluten till en terminal, oavsett --quiet.

-f
--force

Vid byte av gren, fortsätt även om indexet eller arbetsträdet skiljer sig från HEAD, och även om det finns ospårade filer i vägen. Detta används för att ta bort lokala ändringar och eventuella ospårade filer eller kataloger som är i vägen.

Vid utcheckning av sökvägar från indexet, misslyckas inte med ej sammanslagna poster; i stället ignoreras ej sammanslagna poster.

--ours
--theirs

Vid utcheckning av sökvägar från indexet, kontrollera steg #2 (vår) eller #3 (deras) för ej sammanslagna sökvägar.

Observera att under git rebase och git pull --rebase kan vår och deras verka omväxlande; --ours anger versionen från grenen som ändringarna ombaseras på, medan --theirs anger versionen från grenen som innehåller ditt arbete som ombaseras.

Det beror på att rebase används i ett arbetsflöde som behandlar historiken på fjärren som den delade kanoniska, och behandlar arbetet som utförs på grenen som ombaseras som tredjepartsarbete som ska integreras, och rollen som behållare av den kanoniska historiken antas tillfälligt under ombaseringen. Som behållare av den kanoniska historiken måste historiken ses historiken från fjärren som vår (dvs. "vår delade kanoniska historik"), medan det som gjordes på sidogrenen ses som deras (dvs. "en bidragsgivares arbete ovanpå den").

-b <ny-gren>

Skapa en ny gren med namnet <my-gren>, starta den vid <start-punkt> och kontrollera den resulterande utgreningen; se git-branch[1] för mer information.

-B <ny-gren>

Samma som -b, förutom att om grenen redan finns återställer den <gren> till startpunkten i stället för att misslyckas.

-t
--track[=(direct|inherit)]

När du skapar en ny gren, konfigurera "uppström". Se --track i git-branch[1] för mer information. För enkelhetens skull innebär --track utan -b att man skapar en gren.

Om inget -b-alternativ anges, kommer namnet på den nya grenen att härledas från fjärrspårnings-grenen, genom att titta på den lokala delen av referensspecifikationen som är konfigurerad för motsvarande fjärr, och sedan ta bot den initiala delen upp till "*". Detta skulle ange att vi ska använda hack som lokal gren när vi förgrenar oss från origin/hack (eller remotes/origin/hack, eller till och med refs/remotes/origin/hack). Om det angivna namnet inte har något snedstreck, eller om ovanstående gissning resulterar i ett tomt namn, avbryts gissningen. Du kan explicit ange ett namn med -b i ett sådant fall.

--no-track

Skapa inte en "uppströms"-konfiguration, även om konfigurationsvariabeln branch.autoSetupMerge är sann.

--guess
--no-guess

Om <gren> inte hittas men det finns en spårningsgren i exakt en fjärr (kalla den <fjärr>) med ett matchande namn, behandla den som likvärdig med

$ git checkout -b <gren> --track <fjärr>/<gren>

Om grenen finns i flera fjärrar och en av dem namnges av konfigurationsvariabeln checkout.defaultRemote använder vi den för att göra tolkningen tydligare, även om <gren> inte är unik över alla fjärrar. Sätt den till t.ex. checkout.defaultRemote=origin för att alltid checka ut fjärrgrenar därifrån om <gren> är tvetydig men finns på fjärren origin. Se även checkout.defaultRemote i git-config[1].

--guess är standardbeteendet. Använd --no-guess för att inaktivera det.

Standardbeteendet kan ställas in via konfigurationsvariabeln checkout.guess.

-l

Skapa den nya grenens reflog; se git-branch[1] för mer information.

-d
--detach

I stället för att checka ut en gren för att arbeta med den, checka ut en incheckning för inspektion och kasserbara experiment. Detta är standardbeteendet för git checkout <incheckning> när <incheckning> inte är ett grennamn. Se avsnittet "FRÅNKOPPLAT HUVUD (HEAD)" nedan för mer information.

--orphan <ny-gren>

Skapa en ny ofödd gren, med namnet <ny-gren>, startad från <start-punkt> och byt till den. Den första incheckning som görs på den här nya grenen kommer inte att ha några föräldrar och den kommer att vara roten till en ny historik som är helt frikopplad från alla andra grenar och incheckningar.

Indexet och arbetsträdet justeras som om git checkout <start-punkt>. Detta gör det möjligt att starta en ny historik som registrerar en uppsättning sökvägar liknande <start-punkt> genom att enkelt köra git commit -a för att göra root-incheckningen.

Det kan vara användbart när trädet från en incheckning ska publiceras utan att exponera dess fullständiga historik. Det kan till exempel användas för att publicera en öppen källkodsgren av ett projekt vars nuvarande träd är "rent", men vars fullständiga historik innehåller proprietära eller på annat sätt begränsade kodbitar.

Om en frånkopplad historik ska startas som registrerar en uppsättning sökvägar som är helt annorlunda än den för <startpunkt>, bör indexet och arbetsträdet rensas direkt efter att den föräldralösa grenen har skapats genom att köra git rm -rf . från den översta nivån i arbetsträdet. Efteråt är det möjligt att förbereda de nya filerna, fylla i arbetsträdet igen, kopiera dem från någon annanstans, extrahera en tar-fil, etc.

--ignore-skip-worktree-bits

I glest utchecknings-läge skulle git checkout -- <sökväg>... endast uppdatera poster som matchas av <sökväg> och sparse-mönster i $GIT_DIR/info/sparse-checkout. Det här alternativet ignorerar de sparse-mönstren och lägger tillbaka alla filer i <sökväg>....

-m
--merge

Vid byte av grenar: om det finns lokala ändringar i en eller flera filer som skiljer sig mellan den aktuella grenen och den gren som växlas till, vägrar kommandot att byta gren för att bevara ändringarna i sitt sammanhang. Med det här alternativet görs dock en trevägssammanslagning mellan den aktuella grenen, innehållet i arbetsträdet och den nya grenen, och resultatet blir den nya grenen.

När en sammanslagningskonflikt inträffar, lämnas indexposterna för motstridiga sökvägar ej sammanslagna, och du måste lösa konflikterna och markera de lösta sökvägarna med git add (eller git rm om sammanslagningen ska resultera i borttagning av sökvägen).

När du checkar ut sökvägar från indexet, låter det här alternativet dig återskapa den konfliktfyllda sammanslagningen i de angivna sökvägarna. Det här alternativet kan inte användas när du checkar ut sökvägar från en trädliknande källa.

När man byter grenar med --merge kan ändringar i etapper gå förlorade.

--conflict=<stil>

Samma som alternativet --merge ovan, men ändrar hur de motstridiga styckenerna presenteras och åsidosätter konfigurationsvariabeln merge.conflictStyle. Möjliga värden är merge (standard), diff3 och zdiff3.

-p
--patch

Välj interaktivt bitar i skillnaden mellan <trädlikt> (eller indexet, om inget anges) och arbetsträdet. De valda bitarna tillämpas sedan i omvänd ordning på arbetsträdet (och om ett <trädlikt> angavs, indexet).

Det betyder att git checkout -p kan användas för att selektivt ignorera redigeringar från det nuvarande arbetsträdet. Se avsnittet "Interaktivt läge" i git-add[1] för information om hur --patch-läget.

Observera att det här alternativet använder inte överläggsläget som standard (se även --overlay), och för närvarande stödes inte överläggsläget.

-U<n>
--unified=<n>

Generate diffs with <n> lines of context. The number of context lines defaults to diff.context or 3 if the configuration variable is unset. (-U without <n> is silently accepted as a synonym for -p due to a historical accident).

--inter-hunk-context=<n>

Visar sammanhanget mellan olika stycken, upp till det angivna <antal> rader, och sammanfogar därmed stycken som ligger nära varandra. Standardvärdet är diff.interHunkContext eller 0 om konfigurationsalternativet inte är inställt.

--ignore-other-worktrees

git checkout vägrar när den önskade grenen redan är utcheckad eller på annat sätt används av ett annat arbetsträd. Den här inställningen gör att den ändå checkar ut grenen. Med andra ord kan grenen användas av mer än ett arbetsträd.

--overwrite-ignore
--no-overwrite-ignore

Skriv tyst över ignorerade filer vid byte av gren. Detta är standardbeteendet. Använd --no-overwrite-ignore för att avbryta operationen när den nya grenen innehåller ignorerade filer.

--recurse-submodules
--no-recurse-submodules

Genom att använda --recurse-submodules uppdateras innehållet i alla aktiva undermoduler enligt den incheckningen som registrerats i superprojektet. Om lokala modifieringar i en undermodul skulle skrivas över kommer utcheckningen att misslyckas om inte -f används. Om ingenting (eller --no-recurse-submodules) används kommer undermodulernas arbetsträd inte att uppdateras. Precis som med git-submodule[1] kommer detta att koppla bort HEAD från undermodulen.

--overlay
--no-overlay

I standard överläggsläget, tar git checkout aldrig bort filer från indexet eller arbetsträdet. När --no-overlay anges, tas filer som finnsi indexet och arbetsträdet, men inte i <trädlikt>, bort, så att de matchar <trädlikt> exakt.

--pathspec-from-file=<fil>

Sökvägsmönster skickas i <fil> i stället för kommandoradsargument. Om <fil> är exakt - används standardindata. Sökvägsmönster separeras med LF eller CR/LF. Sökvägsmönster kan citeras enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]). Se även --pathspec-file-nul och globala --literal-pathspecs.

--pathspec-file-nul

Endast meningsfullt med --pathspec-from-file. Sökvägsmönsterposter separeras med tecknet NUL och alla andra tecken tolkas bokstavligt (inklusive radbrytningar och citattecken).

<gren>

Gren till utcheckning; om den refererar till en gren (dvs. ett namn som, när det inleds med "refs/heads/", är en giltig referens), så är den grenen utcheckad. Annars, om den refererar till en giltig incheckning, blir din HEAD "frånkopplad" och du är inte längre på någon gren (se nedan för detaljer).

Du kan använda syntaxen @{-N} för att referera till den N:te sista grenen/incheckningen som checkats ut med hjälp av operationen "git checkout". Du kan också ange - vilket är synonymt med @{-1}.

Som ett specialfall kan du använda <rev-a>...<rev-b> som en genväg för sammanslagningsbasen för <rev-a> och <rev-b> om det finns exakt en sammanslagningsbas. Du kan utelämna högst en av <rev-a> och <rev-b>, i vilket fall standardvärdet är HEAD.

<ny-gren>

Namn på den nya grenen.

<start-punkt>

Namnet på en incheckning där den nya grenen ska startas; se git-branch[1] för mer information. Standardvärdet är HEAD.

Som ett specialfall kan du använda <rev-a>...<rev-b> som en genväg för sammanslagningsbasen för <rev-a> och <rev-b> om det finns exakt en sammanslagningsbas. Du kan utelämna högst en av <rev-a> och <rev-b>, i vilket fall standardvärdet är HEAD.

<trädlikt>

Träd att checka ut från (när sökvägar anges). Om inget anges kommer indexet att användas.

Som ett specialfall kan du använda <rev-a>...<rev-b> som en genväg för sammanslagningsbasen för <rev-a> och <rev-b> om det finns exakt en sammanslagningsbas. Du kan utelämna högst en av <rev-a> och <rev-b>, i vilket fall standardvärdet är HEAD.

--

Tolka inte fler argument som alternativ.

<sökvägsmönster>...

Begränsar de sökvägar som påverkas av operationen.

För mer information, se posten sökvägsmönster i gitglossary[7].

FRÅNKOPPLAT HEAD

HEAD refererar normalt till en namngiven gren (t.ex. master). Varje gren refererar däremot till en specifik incheckning. Låt oss titta på ett kodförråd med tre incheckningar, varav en är taggad, och med grenen master utcheckad:

           HEAD (hänvisar till gren 'master')
            |
            v
a---b---c  gren 'master' (rhänvisar to incheckning 'c')
    ^
    |
  tagg 'v2.0' (hänvisar till incheckning 'b')

När en incheckning skapas i detta tillstånd uppdateras grenen för att referera till den nya incheckningen. Mer specifikt skapar git commit en ny incheckning d, vars förälder är incheckning c, och uppdaterar sedan grenen master för att referera till den nya incheckningen d. HEAD refererar fortfarande till grenen master och refererar därför nu indirekt till incheckning d:

$ edit; git add; git commit

               HEAD (hänvisar till gren 'master')
                |
                v
a---b---c---d  gren 'master' (hänvisar till incheckning 'd')
    ^
    |
  tagg 'v2.0' (hänvisar till incheckning 'b')

Det är ibland användbart att kunna checka ut en incheckning som inte finns i toppen av någon namngiven gren, eller till och med att skapa en ny incheckning som inte refereras av en namngiven gren. Låt oss titta på vad som händer när vi checkar ut incheckning b (här visar vi två sätt detta kan göras):

$ git checkout v2.0  # eller
$ git checkout master^^

   HEAD (hänvisar till incheckning 'b')
    |
    v
a---b---c---d  gren 'master' (hänvisar till incheckning 'd')
    ^
    |
  tagg 'v2.0' (hänvisar till incheckning 'b')

Observera att oavsett vilket checkout-kommando vi använder, refererar HEAD nu direkt till incheckning b. Detta kallas att vara i frånkopplat HEAD-tillstånd. Det betyder helt enkelt att HEAD refererar till en specifik incheckning, i motsats till att referera till en namngiven gren. Låt oss se vad som händer när vi skapar en incheckning:

$ edit; git add; git commit

     HEAD (hänvisar till incheckning 'e')
      |
      v
      e
     /
a---b---c---d  gren 'master' (hänvisar till incheckning 'd')
    ^
    |
  tagg 'v2.0' (hänvisar till incheckning 'b')

Det finns nu en ny incheckning e, men den refereras endast av HEAD. Vi kan naturligtvis lägga till ytterligare en incheckning i detta tillstånd:

$ edit; git add; git commit

	 HEAD (hänvisar till incheckning 'f')
	  |
	  v
      e---f
     /
a---b---c---d  gren 'master' (hänvisar till incheckning 'd')
    ^
    |
  tagg 'v2.0' (hänvisar till incheckning 'b')

Faktum är att vi kan utföra alla vanliga Git-operationer. Men låt oss titta på vad som händer när vi sedan checkar ut master:

$ git checkout master

               HEAD (hänvisar till gren 'master')
      e---f     |
     /          v
a---b---c---d  gren 'master' (refers to incheckning 'd')
    ^
    |
  tag 'v2.0' (hänvisar till incheckning 'b')

Det är viktigt att inse att ingenting i nuläget refererar till incheckning f. Så småningom kommer incheckning f (och i förlängningen incheckning e) att raderas av Gits rutinmässiga skräpinsamlingsprocess, såvida vi inte skapar en referens innan det händer. Om vi inte ännu har gått ifrån incheckning f kommer någon av dessa att skapa en referens till den:

$ git checkout -b foo  # eller "git switch -c foo"  (1)
$ git branch foo                                 (2)
$ git tag foo                                    (3)

  1. skapar en ny gren foo, som refererar till incheckning f, och uppdaterar sedan HEAD för att referera till grenen foo. Med andra ord, vi kommer inte längre att vara i frånkopplat-HEAD läge efter detta kommando.

  2. på liknande sätt skapar man en ny gren foo, som refererar till incheckning f, men lämnar HEAD fristående.

  3. skapar en ny tagg foo, som refererar till incheckning f, och lämnar HEAD frånkopplat.

Om vi har gått ifrån incheckning f måste vi först återställa dess objektnamn (vanligtvis med hjälp av git reflog), och sedan kan vi skapa en referens till det. För att till exempel se de två sista incheckningarna som HEAD refererade till kan vi använda något av dessa kommandon:

$ git reflog -2 HEAD # eller
$ git log -g -2 HEAD

ARGUMENT SÄRSKILJNING

När du kör git checkout <något> försöker Git gissa om <något> är avsedd att vara en gren, en incheckning eller en uppsättning filer, och växlar sedan antingen till den grenen eller incheckningen, eller återställer de angivna filerna.

Om det finns någon tvetydighet kommer Git att behandla <något> som en gren eller incheckning, men du kan använda det dubbla bindestrecket -- för att tvinga Git att behandla parametern som en lista med filer och/eller kataloger, så här:

git checkout -- fil.txt

EXEMPEL

1. Sökvägar

Följande sekvens kontrollerar grenen master, återställer Makefile till två versioner bakåt, tar bort hello.c av misstag och hämtar tillbaka den från indexet.

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)

  1. byt gren

  2. ta en fil från en annan incheckning

  3. återställ hello.c från indexet

Om du vill checka ut alla C-källkods-filer från indexet kan du säga

$ git checkout -- '*.c'

Observera citattecknen runt *.c. Filen hello.c kommer också att checkas ut, även om den inte längre finns i arbetsträdet, eftersom filglobbing används för att matcha poster i indexet (inte i arbetsträdet av skalet).

Om du har en olycklig gren som heter hello.c, skulle detta steg förväxlas med en instruktion för att byta till den grenen. Du bör i stället skriva:

$ git checkout -- hello.c

2. Sammanslagning

Efter att ha arbetat i fel gren, skulle byte till rätt gren göras med hjälp av:

$ git checkout mittämne

Din "felaktiga" gren och korrekta mittämne-gren kan dock skilja sig åt i filer som du har modifierat lokalt, i vilket fall utcheckningen ovan skulle misslyckas så här:

$ git checkout mittämne
error: You have local changes to 'frotz'; not switching branches.

Du kan ge flaggan -m till kommandot, vilket skulle försöka en trevägssammanslagning:

$ git checkout -m mittämne
Auto-merging frotz

Efter denna trevägssammanslagning registreras de lokala modifieringarna inte i din indexfil, så git diff skulle visa dig vilka ändringar du gjort sedan starten av den nya grenen.

3. Sammanslagningskonflikt

När en sammanslagningskonflikt uppstår vid byte av grenar med alternativet -m, skulle du se något liknande:

$ git checkout -m mittämne
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed

Vid det här laget, visar git diff ändringarna tydligt sammanfogade som i föregående exempel, såväl som ändringarna i de konfliktfyllda filerna. Redigera och lös konflikten och markera den som löst med git add som vanligt:

$ edit frotz
$ git add frotz

KONFIGURATION

Allt under den här raden i det här avsnittet är selektivt inkluderat från dokumentationen git-config[1]. Innehållet är detsamma som det som finns där:

checkout.defaultRemote

När du kör git checkout <något> eller git switch <något> och bara har en fjärr, kan den implicit återgå till att checka ut och spåra, t.ex. origin/<något>. Detta slutar fungera så fort du har mer än en fjärr med en <något>-referens. Den här inställningen gör det möjligt att ställa in namnet på en föredragen fjärr som alltid ska vinna vid särskiljning. Det typiska användningsfallet är att ställa in detta till origin.

För närvarande används detta av git-switch[1] och git-checkout[1] när git checkout <något> eller git switch <något> checkar ut grenen <något> på en annan fjärr, och av git-worktree[1] när git worktree add refererar till en fjärrgren. Denna inställning kan komma att användas för andra checkout-liknande kommandon eller funktioner i framtiden.

checkout.guess

Anger standardvärdet för alternativen --guess eller --no-guess i git checkout och git switch. Se git-switch[1] och git-checkout[1].

checkout.workers

Antalet parallella arbetare som ska användas vid uppdatering av arbetsträdet. Standardvärdet är ett, d.v.s. sekventiell exekvering. Om det sätts till ett värde mindre än ett, kommer Git att använda lika många arbetare som antalet tillgängliga logiska kärnor. Inställningen och checkout.thresholdForParallelism påverkar alla kommandon som utför utcheckning. T.ex. checkout, clone, reset, sparse-checkout, etc.

Note
 Parallell utcheckning ger vanligtvis bättre prestanda för kodförråd som finns på SSD-diskar eller över NFS. För kodförråd på roterande diskar och/eller maskiner med ett litet antal kärnor fungerar standard sekventiell utcheckning ofta bättre. Storleken och komprimeringsnivån för ett kodförrådet kan också påverka hur bra den parallella versionen presterar.
checkout.thresholdForParallelism

När man kör parallell utcheckning med ett litet antal filer kan kostnaden för att skapa underprocesser och kommunikation mellan processer överväga vinsterna med parallellisering. Den här inställningen låter dig definiera det minsta antalet filer som parallell utcheckning ska försökas för. Standardinställningen är 100.

SE ÄVEN

git-switch[1], git-restore[1]

GIT

En del av git[1]-sviten