Svenska ▾ Topics ▾ Latest version ▾ git-switch last updated in 2.51.0

NAMN

git-switch - Växla grenar

SYNOPSIS

git switch [<options>] [--no-guess] <gren>
git switch [<options>] --detach [<start-punkt>]
git switch [<options>] (-c|-C) <ny-gren> [<start-punkt>]
git switch [<options>] --orphan <ny-gren>

BESKRIVNING

Växla till en angiven gren. Arbetskatalogen och indexet uppdateras för att matcha grenen. Alla nya incheckningar läggs till i toppen av denna gren.

Valfritt kan en ny gren skapas med antingen -c, -C, automatiskt från en fjärrgren med samma namn (se --guess), eller koppla bort arbetskatalogen från vilken gren som helst med --detach, tillsammans med växling.

Att byta gren kräver inte ett rent index och arbetskatalog (dvs. inga skillnader jämfört med HEAD). Operationen avbryts dock om operationen leder till förlust av lokala ändringar, om inte annat anges med --discard-changes eller --merge.

ALTERNATIV

<gren>

Gren att byta till.

<ny-gren>

Namn på den nya grenen.

<start-punkt>

Startpunkten för den nya grenen. Genom att ange en <start-punkt> kan du skapa en gren baserad på någon annan punkt i historiken än där HEAD för närvarande pekar. (Eller, i fallet med --detach, kan du inspektera och koppla bort från någon annan punkt.)

Du kan använda syntaxen @{-<N>} för att referera till den <N>:e sista grenen/incheckningen som byttes till med git switch eller git checkout operationen. Du kan också ange - vilket är synonymt med @{-1}. Detta används ofta för att snabbt växla mellan två grenar, eller för att ångra ett grenbyte av misstag.

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.

-c <ny-gren>
--create <ny-gren>

Skapa en ny gren med namnet <ny-gren> med början vid <start-punkt> innan du byter till grenen. Detta är den transaktionella motsvarigheten till

$ git branch <ny-gren>
$ git switch <ny-gren>

det vill säga, grenen återställs/skapas inte om inte git switch lyckas (t.ex. när grenen används i ett annat arbetsträd, förblir inte bara den aktuella grenen densamma, utan grenen återställs inte heller till startpunkten).

-C <ny-gren>
--force-create <ny-gren>

Liknar --create förutom att om <ny-gren> redan finns, kommer den att återställas till <start-punkt>. Detta är en bekväm genväg för:

$ git branch -f _<ny-gren>_
$ git switch _<ny-gren>_
-d
--detach

Växla till en incheckning för inspektion och kasserbara experiment. Se avsnittet "FRÅNKOPPLAT HEAD" i git-checkout[1] för mer information.

--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 switch -c <gren> --track <fjärr>/<gren>

Om grenen finns i flera fjärrer och en av dem namnges av konfigurationsvariabeln checkout.defaultRemote, kommer vi att använda den för att göra det tydligare, även om <gren> inte är unik för alla fjärrer. Ställ in 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.

-f
--force

Ett alias för --discard-changes.

--discard-changes

Fortsätt även om indexet eller arbetskatalogen skiljer sig från HEAD. Både indexet och arbetskatalogen återställs för att matcha växlingsmålet. Om --recurse-submodules anges återställs även undermoduls-innehållet för att matcha växlingsmålet. Detta används för att ignorera lokala ändringar.

-m
--merge

Om du har lokala ändringar i en eller flera filer som skiljer sig mellan den aktuella grenen och den gren du växlar till, vägrar kommandot att växla grenar för att bevara dina ändringar i kontext. Med det här alternativet sker dock en trevägssammanslagning mellan den aktuella grenen, innehållet i ditt arbetskatalog och den nya grenen, och du kommer att vara på 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).

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

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

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

När du skapar en ny gren, konfigurera "uppströms". -c är underförstått. Se --track i git-branch[1] för mer information.

Om inget -c-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 referensspecifikation:en som är konfigurerad för motsvarande fjärr, och sedan strippa 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 -c i ett sådant fall.

--no-track

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

--orphan <ny-gren>

Skapa en ny ofödd gren med namnet <ny-gren>. Alla spårade filer tas bort.

--ignore-other-worktrees

git switch vägrar när den önskade referensen redan är utcheckad av ett annat arbetsträd. Den här inställningen gör att referensen ändå checkas ut. Med andra ord kan referensen hållas av mer än ett arbetsträd.

--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 ingenting (eller --no-recurse-submodules) används, kommer inte undermodulernas arbetskatalogerer att uppdateras. Precis som i git-submodule[1] kommer detta att koppla bort HEAD från undermodulerna.

EXEMPEL

Följande kommando växlar till grenen "master":

$ git switch master

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

$ git switch mittämne

Dock, din "felaktiga" gren och korrekta "mittämnes"-gren kan dock skilja sig åt i filer som du har ändrat lokalt, i vilket fall ovanstående växel skulle misslyckas så här:

$ git switch mytopic
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 switch -m mittämne
Slår ihop frotz automatiskt

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.

För att växla tillbaka till föregående gren innan vi bytte till mittämne (dvs. "master"-grenen):

$ git switch -

Du kan skapa en ny gren från vilken incheckning som helst. Till exempel, byt till "HEAD~3" och skapa grenen "fixup":

$ git switch -c fixup HEAD~3
Växlade till en ny gren "fixup"

Om du vill starta en ny gren från en fjärrgren med samma namn:

$ git switch new-topic
Branch `new-topic` set up to track remote branch `new-topic` from `origin`
Switched to a new branch `new-topic`

För att checka ut incheckning HEAD~3 för tillfällig inspektion eller experiment utan att skapa en ny gren:

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

Om det visar sig att det du har gjort är värt att behålla, kan du alltid skapa ett nytt namn för det (utan att byta namn):

$ git switch -c bra-överraskningar

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 arbetskatalogen. Standardvärdet är ett, dvs. 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. Denna inställning 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 förvar som finns på SSD-diskar eller över NFS. För förvar 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 förvaret 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-checkout[1], git-branch[1]

GIT

En del av git[1]-sviten