git-checkout(1)
git-checkout(1)
NAMN
git-checkout – byt gren eller återställ filer i arbetskatalogen
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-gren>] [<startpunkt>] git checkout <trädliknande> [--] <pathspec>... git checkout <trädliknande> --pathspec-from-file=<fil> [--pathspec-file-nul] git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] [--] <pathspec>... git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] --pathspec-from-file=<fil> [--pathspec-file-nul] git checkout (-p|--patch) [<trädliknande>] [--] [<pathspec>...]
BESKRIVNING
git checkout har två huvudlägen:
- Byta gren, med git checkout <gren>.
- Återställa en annan version av en fil, till exempel med git checkout <incheckning> <filnamn> eller git checkout <filnamn>.
Se avsnittet ARGUMENTDISAMBIGUERING nedan för hur Git avgör vilket av dessa lägen som avses.
git checkout [<gren>]
- Byt till <gren>. Detta sätter den aktuella grenen till <gren> och uppdaterar filerna i arbetskatalogen. Utcheckningen misslyckas om det finns ej incheckade ändringar i filer där <gren> och din aktuella incheckning har olika innehåll. Ej incheckade ändringar bevaras annars.
- Om <gren> inte finns, men det finns en spårningsgren med samma namn i exakt en fjärrkälla (<fjärr>) och --no-guess inte anges, behandlas kommandot som:
$ git checkout -b <gren> --track <fjärr>/<gren>
- Om git checkout körs utan att en gren anges har det ingen annan effekt än att skriva ut spårningsinformation för den aktuella grenen.
git checkout -b <ny-gren> [<startpunkt>]
- Skapa en ny gren med namnet <ny-gren>, starta den vid <startpunkt> (standard är aktuell incheckning) och checka ut den nya grenen. Alternativen --track och --no-track kan användas för att styra grenens uppströmsinformation.
- Kommandot misslyckas om ett fel inträffar vid utcheckning av <ny-gren>, till exempel om <startpunkt> skulle skriva över ej incheckade ändringar.
git checkout -B <gren> [<startpunkt>]
- Samma som -b, men om grenen redan finns återställs <gren> till startpunkten i stället för att kommandot misslyckas.
git checkout --detach [<gren>], git checkout [--detach] <incheckning>
- Samma som git checkout <gren>, men i stället för att HEAD pekar på grenen pekar HEAD på inchecknings-ID:t. Se avsnittet FRIKOPPLAD HEAD.
- Om <gren> utelämnas frikopplas HEAD vid toppen av den aktuella grenen.
git checkout <trädliknande> [--] <pathspec>..., git checkout <trädliknande> --pathspec-from-file=<fil> [--pathspec-file-nul]
- Ersätt de angivna filerna och/eller katalogerna med versionen från den angivna incheckningen eller trädet, och lägg dem i indexet (även kallat staging area).
- Exempel: git checkout main file.txt ersätter file.txt med versionen från main.
git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] [--] <pathspec>..., git checkout [-f|--ours|--theirs|-m|--conflict=<stil>] --pathspec-from-file=<fil> [--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 kommer på att ändringarna var fel, kasserar git checkout file.txt alla ej mellanlagrade ändringar i file.txt.
- Kommandot misslyckas om filen har en sammanslagningskonflikt och du ännu inte har kört git add file.txt eller motsvarande för att markera den som löst. Du kan använda -f för att ignorera osammanslagna filer, --ours eller --theirs för att välja en viss sida av sammanslagningen, eller -m för att återskapa det ursprungliga konfliktresultatet.
git checkout (-p|--patch) [<trädliknande>] [--] [<pathspec>...]
- Liknar föregående lägen, men använder ett interaktivt gränssnitt där du får se diff-utdata och välja vilka stycken som ska användas. Se beskrivningen av --patch nedan.
ALTERNATIV
-q, --quiet
- Tyst läge; undertryck återkopplingsmeddelanden.
--progress, --no-progress
- Förloppsstatus rapporteras normalt på standardfel när den är ansluten till en terminal, om inte --quiet anges. Denna flagga aktiverar förloppsrapportering även när standardfel inte är en terminal.
-f, --force
- Vid grenbyte: fortsätt även om indexet eller arbetskatalogen skiljer sig från HEAD, och även om ospårade filer ligger i vägen. Detta används för att kasta lokala ändringar samt ospårade filer eller kataloger som blockerar bytet.
- Vid utcheckning av sökvägar från indexet: misslyckas inte på osammanslagna poster; de ignoreras i stället.
--ours, --theirs
- Vid utcheckning av sökvägar från indexet: checka ut steg #2 (ours) eller #3 (theirs) för osammanslagna sökvägar.
- Under git rebase och git pull --rebase kan ours och theirs verka omkastade. --ours ger versionen från grenen som ändringarna baseras om på, medan --theirs ger versionen från grenen med ditt arbete.
- Detta beror på att rebase tillfälligt behandlar fjärrhistoriken som den gemensamma kanoniska historiken och ditt arbete som bidraget som ska integreras.
-b <ny-gren>
- Skapa en ny gren med namnet <ny-gren>, starta den vid <startpunkt> och checka ut resultatet. Se git-branch(1).
-B <ny-gren>
- Samma som -b, men om grenen redan finns återställs den till startpunkten i stället för att kommandot misslyckas.
-t, --track[=(direct|inherit)]
- När en ny gren skapas, ställ in uppströmskonfiguration. Se --track i git-branch(1). Som bekvämlighet innebär --track utan -b att en gren skapas.
- Om inget -b anges härleds namnet på den nya grenen från fjärrspårningsgrenen genom att använda den lokala delen av refspec för fjärrkällan. Vid förgrening från origin/hack används exempelvis hack som lokalt grennamn. Om gissningen inte ger ett användbart namn avbryts den; ange i så fall namnet uttryckligen med -b.
--no-track
- Ställ inte in uppströmskonfiguration, även om branch.autoSetupMerge är sann.
--guess, --no-guess
- Om <gren> inte hittas men en spårningsgren med samma namn finns i exakt en fjärrkälla, behandlas det som:
$ git checkout -b <gren> --track <fjärr>/<gren>
- Om grenen finns i flera fjärrkällor och en av dem anges av checkout.defaultRemote, används den för att lösa tvetydigheten. Detta kan till exempel sättas till origin för att alltid föredra den fjärrkällan när namnet annars är tvetydigt. Se git-config(1).
- --guess är standardbeteende. Använd --no-guess för att inaktivera det. Standardbeteendet kan anges via checkout.guess.
-l
- Skapa reflog för den nya grenen. Se git-branch(1).
-d, --detach
- Checka ut en incheckning för granskning och tillfälliga experiment i stället för att checka ut en gren. Detta är standard när git checkout <incheckning> används och <incheckning> inte är ett grennamn. Se FRIKOPPLAD HEAD.
--orphan <ny-gren>
- Skapa en ny ofödd gren med namnet <ny-gren>, startad från <startpunkt>, och byt till den. Den första incheckningen på grenen saknar föräldrar och blir roten till en ny historik som är helt frånkopplad från alla andra grenar och incheckningar.
- Indexet och arbetskatalogen justeras som om du tidigare hade kört git checkout <startpunkt>. Detta gör det enkelt att skapa en ny rotincheckning med ett träd som liknar <startpunkt>.
- Detta kan användas när du vill publicera ett projektträd utan att exponera hela historiken, till exempel om historiken innehåller proprietär kod.
- Om du vill starta med helt annat innehåll bör du rensa indexet och arbetskatalogen efter att grenen skapats:
git rm -rf .
- Därefter kan arbetskatalogen fyllas med nya filer från annat håll.
--ignore-skip-worktree-bits
- I sparse checkout-läge uppdaterar git checkout -- <path>... normalt bara poster som matchar sökvägarna och sparse-mönstren i $GIT_DIR/info/sparse-checkout. Detta alternativ ignorerar sparse-mönstren och lägger tillbaka alla filer i de angivna sökvägarna.
-m, --merge
- Vid grenbyte: om lokala ändringar skiljer sig från både aktuell gren och grenen du byter till vägrar Git normalt byta gren. Med detta alternativ sparas motstridiga lokala ändringar tillfälligt före bytet och appliceras igen efteråt. Om återappliceringen ger konflikter sparas posten i stash-listan. Lös konflikterna och kör git stash drop, eller rensa arbetskatalogen med exempelvis git reset --hard innan du senare kör git stash pop.
- Vid utcheckning av sökvägar från indexet återskapar detta alternativ den konfliktfyllda sammanslagningen i de angivna sökvägarna. Det kan inte användas när sökvägar checkas ut från ett trädliknande objekt.
--conflict=<stil>
- Samma som --merge, men ändrar hur konfliktstycken visas. Detta åsidosätter merge.conflictStyle. Möjliga värden är merge (standard), diff3 och zdiff3.
-p, --patch
- Välj interaktivt stycken i skillnaden mellan <trädliknande> (eller indexet om inget anges) och arbetskatalogen. De valda styckena appliceras sedan omvänt på arbetskatalogen, och även på indexet om ett <trädliknande> objekt angavs.
- Detta gör det möjligt att selektivt kasta redigeringar från arbetskatalogen med git checkout -p. Se avsnittet ”Interactive Mode” i git-add(1).
- Alternativet använder läget utan overlay som standard och stöder för närvarande inte overlay-läge.
-U<n>, --unified=<n>
- Generera diffar med <n> rader sammanhang. Standard är diff.context eller 3 om inställningen saknas. -U utan <n> accepteras av historiska skäl som synonym för -p.
--inter-hunk-context=<n>
- Visa sammanhang mellan diffstycken, upp till angivet antal rader, vilket kan slå ihop stycken som ligger nära varandra. Standard är diff.interHunkContext eller 0.
--ignore-other-worktrees
- Tillåt utcheckning även om den önskade grenen redan är utcheckad eller används av ett annat worktree.
--overwrite-ignore, --no-overwrite-ignore
- Skriv tyst över ignorerade filer vid grenbyte. Detta är standard. Använd --no-overwrite-ignore för att avbryta om den nya grenen innehåller ignorerade filer som skulle skrivas över.
--recurse-submodules, --no-recurse-submodules
- Med --recurse-submodules uppdateras innehållet i alla aktiva undermoduler enligt incheckningen i superprojektet. Om lokala ändringar i en undermodul skulle skrivas över misslyckas kommandot om inte -f används. Utan detta alternativ uppdateras inte undermodulernas arbetskataloger. Precis som git-submodule(1) frikopplas HEAD i undermodulen.
--overlay, --no-overlay
- I standardläget overlay tar git checkout aldrig bort filer från indexet eller arbetskatalogen. Med --no-overlay tas filer bort om de finns i indexet och arbetskatalogen men inte i <trädliknande>, så att resultatet matchar exakt.
--pathspec-from-file=<fil>
- Läs pathspec från <fil> i stället för från kommandoradsargument. Om <fil> är - används standardindata. Element separeras med LF eller CR/LF. De kan citeras enligt core.quotePath; se git-config(1). Se även --pathspec-file-nul och --literal-pathspecs.
--pathspec-file-nul
- Endast meningsfullt med --pathspec-from-file. Pathspec-element separeras med NUL-tecken och alla andra tecken tolkas bokstavligt.
<gren>
- Gren att checka ut. Om namnet hänvisar till en gren, checkas grenen ut. Om det hänvisar till en giltig incheckning blir HEAD frikopplad.
- Syntaxen @{-N} hänvisar till den N:e senast utcheckade grenen eller incheckningen. - är synonymt med @{-1}.
- Som specialfall kan <rev-a>...<rev-b> användas som genväg för mergebasen mellan revisionerna, om det finns exakt en mergebas. Högst en sida kan utelämnas; då används HEAD.
<ny-gren>
- Namn på den nya grenen.
<startpunkt>
- Namnet på den incheckning där den nya grenen ska starta. Standard är HEAD. Se git-branch(1). Specialformen <rev-a>...<rev-b> fungerar även här som genväg för mergebasen.
<trädliknande>
- Träd att checka ut från när sökvägar anges. Om inget anges används indexet. Specialformen <rev-a>...<rev-b> fungerar även här som genväg för mergebasen.
--
- Tolka inga efterföljande argument som alternativ.
<pathspec>...
- Begränsar vilka sökvägar åtgärden påverkar. Se posten pathspec i gitglossary(7).
FRIKOPPLAD HEAD
HEAD hänvisar normalt till en namngiven gren, till exempel master. Varje gren hänvisar i sin tur till en specifik incheckning. Exempel med tre incheckningar, en tagg och grenen master utcheckad:
HEAD (hänvisar till grenen 'master')
|
v
a---b---c grenen 'master' (hänvisar till incheckningen 'c')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
När en incheckning skapas i detta läge uppdateras grenen till den nya incheckningen. git commit skapar exempelvis incheckning d, med c som förälder, och uppdaterar master till d. HEAD hänvisar fortfarande till master och därmed indirekt till d:
$ edit; git add; git commit
HEAD (hänvisar till grenen 'master')
|
v
a---b---c---d grenen 'master' (hänvisar till incheckningen 'd')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
Det kan vara användbart att checka ut en incheckning som inte ligger vid toppen av en namngiven gren, eller att skapa incheckningar utan att de direkt refereras av en gren. Om incheckning b checkas ut:
$ git checkout v2.0 # eller
$ git checkout master^^
HEAD (hänvisar till incheckningen 'b')
|
v
a---b---c---d grenen 'master' (hänvisar till incheckningen 'd')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
HEAD hänvisar då direkt till incheckning b i stället för till en gren. Detta kallas frikopplad HEAD. Om en ny incheckning görs skapas exempelvis e, som endast nås via HEAD:
$ edit; git add; git commit
HEAD (hänvisar till incheckningen 'e')
|
v
e
/
a---b---c---d grenen 'master' (hänvisar till incheckningen 'd')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
Ytterligare en incheckning kan skapas i samma läge:
$ edit; git add; git commit
HEAD (hänvisar till incheckningen 'f')
|
v
e---f
/
a---b---c---d grenen 'master' (hänvisar till incheckningen 'd')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
Alla normala Git-kommandon kan användas. Men när du sedan checkar ut master igen finns inget längre som hänvisar till f:
$ git checkout master
HEAD (hänvisar till grenen 'master')
e---f |
/ v
a---b---c---d grenen 'master' (hänvisar till incheckningen 'd')
^
|
taggen 'v2.0' (hänvisar till incheckningen 'b')
Incheckning f och därmed e kan till slut tas bort av Gits normala garbage collection om ingen referens skapas. Om du ännu inte lämnat f kan någon av följande skapa en referens:
$ 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 hänvisar till f och flyttar HEAD till grenen, vilket avslutar frikopplat HEAD-läge.
2. Skapar också grenen foo vid f, men lämnar HEAD frikopplad.
3. Skapar en tagg foo vid f och lämnar HEAD frikopplad.
Om du redan har lämnat f måste du först hitta dess objektnamn, ofta med reflog, och sedan skapa en referens. De två senaste incheckningarna som HEAD hänvisade till visas exempelvis med:
$ git reflog -2 HEAD # eller $ git log -g -2 HEAD
ARGUMENTDISAMBIGUERING
När du kör git checkout <något> försöker Git avgöra om <något> är en gren, en incheckning eller en uppsättning filer. Därefter byter Git antingen till grenen eller incheckningen, eller återställer de angivna filerna.
Om det finns tvetydighet behandlar Git <något> som en gren eller incheckning. Du kan använda dubbelt bindestreck -- för att tvinga Git att behandla argumentet som filer eller kataloger:
git checkout -- file.txt
EXEMPEL
1. Sökvägar
Följande sekvens checkar ut grenen master, återställer Makefile till två revisioner bakåt, råkar ta bort hello.c och hämtar sedan tillbaka filen 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. Hämta en fil från en annan incheckning.
3. Återställ hello.c från indexet.
Om du vill checka ut alla C-källfiler från indexet kan du skriva:
$ git checkout -- '*.c'
Citattecknen runt *.c är viktiga. Filen hello.c checkas också ut även om den inte längre finns i arbetskatalogen, eftersom globbningen matchar poster i indexet, inte filer som skalet hittar i arbetskatalogen.
Om du råkar ha en gren som heter hello.c kan kommandot misstolkas som ett grenbyte. Skriv då i stället:
$ git checkout -- hello.c
2. Sammanslagning
Efter arbete i fel gren kan du byta till rätt gren med:
$ git checkout mytopic
Om den felaktiga grenen och grenen mytopic skiljer sig åt i filer som du har ändrat lokalt misslyckas kommandot, exempelvis:
$ git checkout mytopic error: You have local changes to 'frotz'; not switching branches.
Med flaggan -m kan de lokala ändringarna följa med till den nya grenen:
$ git checkout -m mytopic Applied autostash. Switched to branch 'mytopic' The following paths have local changes: M frotz
Efter bytet appliceras de lokala ändringarna igen och är inte registrerade i indexet. git diff visar därför ändringarna sedan toppen av den nya grenen.
3. Sammanslagningskonflikt
När --merge (-m) anges och lokala ändringar överlappar ändringarna i grenen du byter till, sparas ändringarna tillfälligt och appliceras igen efter bytet. Om detta ger konflikter sparas stash-posten och ett meddelande skrivs ut:
$ git checkout -m mytopic Your local changes are stashed, however applying them resulted in conflicts. You can either resolve the conflicts and then discard the stash with "git stash drop", or, if you do not want to resolve them now, run "git reset --hard" and apply the local changes later by running "git stash pop".
KONFIGURATION
Allt nedan i detta avsnitt är selektivt inkluderat från dokumentationen för git-config(1). Innehållet är detsamma som där.
checkout.defaultRemote
- När du kör git checkout <något> eller git switch <något> och bara har en fjärrkälla kan Git implicit falla tillbaka till att checka ut och spåra exempelvis origin/ <något>. Detta slutar fungera när du har fler än en fjärrkälla med en referens som heter <något>. Denna inställning anger en föredragen fjärrkälla som ska vinna vid tvetydighet. Ett vanligt värde är origin.
- Detta används för närvarande av git-switch(1) och git-checkout(1) när en gren ska checkas ut från en fjärrkälla, och av git-worktree(1) när git worktree add hänvisar till en fjärrgren. Inställningen kan komma att användas av andra checkout-liknande kommandon i framtiden.
checkout.guess
- Anger standardvärdet för --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 när arbetskatalogen uppdateras. Standard är en, alltså sekventiell körning. Om värdet är mindre än ett använder Git lika många arbetare som antalet tillgängliga logiska kärnor. Denna inställning och checkout.thresholdForParallelism påverkar alla kommandon som utför checkout, exempelvis checkout, clone, reset och sparse-checkout.
- Observera att parallell checkout ofta ger bättre prestanda på SSD eller över NFS. För roterande diskar eller maskiner med få kärnor är standardläget ofta snabbare. Arkivets storlek och komprimeringsnivå kan också påverka resultatet.
checkout.thresholdForParallelism
- Vid parallell checkout med få filer kan kostnaden för att starta underprocesser och kommunicera mellan processer bli större än vinsten av parallellisering. Denna inställning anger minsta antal filer för att parallell checkout ska prövas. Standard är 100.
SE ÄVEN
GIT
Del av sviten git(1).
COLOPHON
Denna sida är en del av projektet git (Git distributed version control system). Information om projektet finns på http://git-scm.com/. Om du har en felrapport för denna manualsida, se http://git-scm.com/community. Sidan hämtades från projektets uppströms Git-arkiv på https://github.com/git/git.git den 2026-05-24. Vid den tidpunkten var datumet för den senaste incheckningen som hittades i arkivet 2026-05-22.
Git 2.54.0.254.g6a4418 – 2026-05-22 – GIT-CHECKOUT(1)
Sidor som hänvisar till denna sida
git(1), git-checkout(1), git-commit(1), git-config(1), git-restore(1), git-stash(1), git-switch(1), git-worktree(1), githooks(5), gitrepository-layout(5), gitdatamodel(7)
Sidslut
Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-checkout.1.html
Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på
https://www.linux.se/kontaka-linux-se/
Tack till Datorhjälp hemma som har sponsrat Linux.se med webbhotell.