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

NAMN

git-worktree - Hantera flera arbetsträd

SYNOPSIS

git worktree add [-f] [--detach] [--checkout] [--lock [--reason <sträng>]]
		 [--orphan] [(-b | -B) <ny-gren>] <sökväg> [<incheckningslik>]
git worktree list [-v | --porcelain [-z]]
git worktree lock [--reason <string>] <arbetsträd>
git worktree move <worktree> <ny-sökväg>
git worktree prune [-n] [-v] [--expire <upphör>]
git worktree remove [-f] <arbetsträd>
git worktree repair [<sökväg>…​]
git worktree unlock <arbetsträd>

BESKRIVNING

Hantera flera arbetsträd som är kopplade till samma kodförråd.

Ett Git-kodförråd kan stödja flera arbetsträd, så att mer än en gren kan checkas ut åt gången. Med git worktree add associeras ett nytt arbetsträd med kodförrådet, tillsammans med ytterligare metadata som skiljer det arbetsträdet från andra i samma kodförråd. Arbetsträdet, tillsammans med dessa metadata, kallas ett "worktree".

Detta nya arbetsträd kallas ett "länkat arbetsträd" i motsats till det "huvudarbetsträd" som skapats av git-init[1] eller git-clone[1]. Ett kodförråd har ett huvudarbetsträd (om det inte är ett bart kodförråd) och noll eller fler länkade arbetsträd. När ett länkat arbetsträd inte längre behövs tas det bort med git worktree remove.

I sin enklaste form skapar git worktree add <sökväg> automatiskt en ny gren vars namn är den sista komponenten i <sökväg>, vilket är praktiskt om arbete planeras med ett nytt ämne. Till exempel skapar git worktree add ../hotfix en ny gren hotfix och checkar ut den vid sökvägen ../hotfix. För att i stället arbeta med en befintlig gren i ett nytt arbetsträd används git worktree add <sökväg> <gren>. Å andra sidan, om avsikten bara är att göra några experimentella ändringar eller testa utan att störa befintlig utveckling, är det ofta praktiskt att skapa ett engångs-arbetsträd som inte är associerat med någon gren. Till exempel skapar git worktree add -d <sökväg> ett nytt arbetsträd med en fristående HEAD vid samma incheckning som den aktuella grenen.

Om ett arbetsträd tas bort utan att använda git worktree remove kommer dess tillhörande administrativa filer, som finns i kodförrådet (se "DETALJER" nedan), så småningom att tas bort automatiskt (se gc.worktreePruneExpire i git-config[1]), eller så kan git worktree prune köras i huvudarbetsträdet eller i något länkat arbetsträd för att rensa upp eventuella inaktuella administrativa filer.

Om arbetsträdet för ett länkat arbetsträd lagras på en bärbar enhet eller nätverksresurs som inte alltid är monterad, kan rensning av dess administrativa filer förhindras genom att köra kommandot git worktree lock och valfritt ange --reason för att förklara varför arbetsträdet är låst.

KOMMANDON

add <sökväg> [<incheckningslik>]

Skapa ett arbetsträd vid <sökväg> och checka ut <incheckningslik> i det. Det nya arbetsträdet länkas till det aktuella kodförrådet och delar allt utom filer som är specifika för arbetsträdet, såsom HEAD, index osv. För enkelhetens skull kan <incheckningslik> vara ett rent "-", vilket är synonymt med @{-1}.

Om <incheckningslik> är ett grennamn (kalla det <gren>) och inte hittas, och varken -b, -B eller --detach används, men det finns en spårningsgren med matchande namn i exakt en fjärr (kalla den <fjärr>), behandla det som likvärdigt med:

$ git worktree add --track -b <gren> <sökväg> <fjärr>/<gren>

Om grenen finns i flera fjärrar och en av dem anges med konfigurationsvariabeln checkout.defaultRemote, används den för att göra tolkningen entydig, även om <gren> inte är unik över alla fjärrar. Sätt 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].

Om <incheckningslik> utelämnas och varken -b, -B eller --detach används, associeras det nya arbetsträdet för enkelhetens skull med en gren (kalla den <gren>) med namn efter $(basename <sökväg>). Om <gren> inte finns skapas automatiskt en ny gren baserad på HEAD, som om -b <gren> hade angetts. Om <gren> finns checkas den ut i det nya arbetsträdet, om den inte redan är utcheckad någon annanstans; annars vägrar kommandot att skapa arbetsträdet (om inte --force används).

Om <incheckningslik> utelämnas, varken --detach eller --orphan används, och det inte finns några giltiga lokala grenar (eller fjärrgrenar om --guess-remote anges), associeras det nya arbetsträdet för enkelhetens skull med en ny ofödd gren med namnet <gren> (efter $(basename <sökväg>) om varken -b eller -B används), som om --orphan skickades till kommandot. Om kodförrådet har en fjärr och --guess-remote används men inga fjärr- eller lokala grenar finns, misslyckas kommandot med en varning som påminner användaren om att först hämta från fjärren (eller åsidosätta med -f/--force).

list

Lista detaljer om varje arbetsträd. Huvudarbetsträdet listas först, följt av vart och ett av de länkade arbetsträden. Utdata detaljerna inkluderar om arbetsträdet är bart, vilken revision som för närvarande är utcheckad, vilken gren som för närvarande är utcheckad (eller "detached HEAD" (frikopplad HEAD) om ingen), "locked" om arbetsträdet är låst, "prunable" om arbetsträdet kan beskäras med kommandot prune.

lock

Om ett arbetsträd finns på en portabel enhet eller nätverksresurs som inte alltid är monterad, lås det för att förhindra att dess administrativa filer rensas automatiskt. Detta förhindrar också att det flyttas eller tas bort. En orsak till låsningen kan också anges med --reason.

move

Flytta ett arbetsträd till en ny plats. Observera att huvudarbetsträdet eller länkade arbetsträd som innehåller undermoduler inte kan flyttas med detta kommando. (Kommandot git worktree repair kan dock återupprätta anslutningen till länkade arbetsträd om du flyttar huvudarbetsträdet manuellt.)

prune

Remove worktree information in $GIT_DIR/worktrees for worktrees whose working trees are missing. Useful after manually removing a working tree that is no longer needed (but use "git worktree remove" next time you want to do so). Also, if you moved a working tree elsewhere causing the worktree information to become dangling, see "git worktree repair" to reconnect the worktree to the new working tree location.

remove

Ta bort ett arbetsträd. Endast rena arbetsträd (inga ospårade filer och inga modifieringar i spårade filer) kan tas bort. Orena arbetsträd eller arbetsträd med undermoduler kan tas bort med --force. Huvudarbetsträdet kan inte tas bort.

repair [<sökväg>...]

Reparera arbetsträdets administrativa filer, om möjligt , om de har blivit skadade eller föråldrade på grund av externa faktorer.

Till exempel, om huvudarbetsträdet (eller det bara kodförrådet) flyttas, kommer länkade arbetsträd inte att kunna hitta det. Att köra reparera i huvudarbetsträdet kommer att återupprätta anslutningen från länkade arbetsträd tillbaka till huvudarbetsträdet.

På samma sätt, om arbetsträdet för ett länkat arbetsträd flyttas utan att använda git worktree move, kommer huvudarbetsträdet (eller det bara kodförrådet) inte att kunna hitta det. Att köra repair i det nyligen flyttade arbetsträdet kommer att återupprätta anslutningen. Om flera länkade arbetsträd flyttas, kommer att köra repair från valfritt arbetsträd med varje träds nya <sökväg> som argument, att återupprätta anslutningen till alla angivna sökvägar.

Om både huvudarbetsträdet och länkade arbetsträd har flyttats eller kopierats manuellt, kommer alla anslutningar i båda riktningarna att återställas om man kör reparera i huvudarbetsträdet och anger den nya <sökvägen> för varje länkat arbetsträd.

unlock

Lås upp ett arbetsträd, så att det kan beskäras, flyttas eller tas bort.

ALTERNATIV

-f
--force

Som standard vägrar add att skapa ett nytt arbetsträd när <incheckningslik> är ett grennamn som redan är utcheckat i ett annat arbetsträd, eller om <sökväg> redan är tilldelad ett arbetsträd men saknas (till exempel om <sökväg> har tagits bort manuellt). Flaggan åsidosätter dessa skydd. För att lägga till en saknad men låst arbetsträdssökväg anges --force två gånger.

move vägrar att flytta ett låst arbetsträd om inte --force anges två gånger. Om destinationen redan är tilldelad ett annat arbetsträd men saknas (till exempel om <ny-sökväg> raderades manuellt), så tillåter --force att flytten fortsätter; använd --force två gånger om destinationen är låst.

remove vägrar att ta bort ett orent arbetsträd om inte --force används. För att ta bort ett låst arbetsträd, ange --force två gånger.

-b <ny-gren>
-B <ny-gren>

Med add skapas en ny gren med namnet <ny-gren> som börjar vid <incheckningslik>, och checkar ut <ny-gren> i det nya arbetsträdet. Om <incheckningslik> utelämnas används HEAD som standard. Som standard vägrar -b att skapa en ny gren om den redan finns. -B åsidosätter detta och återställer <ny-gren> till <incheckningslik>.

-d
--detach

Med add, koppla bort HEAD i det nya arbetsträdet. Se "FRÅNKOPPLAT HEAD" i git-checkout[1].

--checkout
--no-checkout

Som standard checkar add ut <incheckningslik>, men --no-checkout kan användas för att undertrycka utcheckning för att göra anpassningar, som att konfigurera gles-utcheckning. Se "gles utcheckning" i git-read-tree[1].

--guess-remote
--no-guess-remote

Med worktree add <sökväg>, utan <incheckningslik>, skapas i stället för en ny gren från HEAD en ny gren baserad på den fjärrspårade grenen om det finns en sådan i exakt en fjärr med samma basnamn som <sökväg>. Den fjärrspårade grenen markeras då som "uppströms" för den nya grenen.

Det kan också ställas in som standardbeteende genom att använda konfigurationsalternativet worktree.guessRemote.

--relative-paths
--no-relative-paths

Länka arbetsträd med relativa sökvägar eller absoluta sökvägar (standard). Åsidosätter konfigurationsalternativet worktree.useRelativePaths, se git-config[1].

Med repair (reparera) uppdateras länkfilerna om det finns en absolut/relativ avvikelse, även om länkarna är korrekta.

--track
--no-track

När en ny gren skapas, om <incheckningslik> är en gren, markera den som "uppströms" från den nya grenen. Detta är standardvärdet om <incheckningslik> är en fjärrspårad gren. Se --track i git-branch[1] för mer information.

--lock

Håll arbetsträdet låst efter skapandet. Detta motsvarar git worktree lock efter git worktree add, men utan en kapplöpningsrisk.

-n
--dry-run

Med prune (beskär), ta inte bort något; rapportera bara vad det skulle ta bort.

--orphan

Med add, lägg till och gör det nya arbetsträdet och indexet tomt, och associera arbetsträdet med en ny ofödd gren med namnet <ny-gren>.

--porcelain

Med list, lista utdata i ett lätttolkat format för skript. Detta format kommer att förbli stabilt i alla Git-versioner och oavsett användarkonfiguration. Det rekommenderas att kombinera detta med -z. Se nedan för detaljer.

-z

Avsluta varje rad med NUL i stället för nyrad när --porcelain anges med list. Detta gör det möjligt att analysera utdata när en arbetsträdssökväg innehåller ett nyradstecken.

-q
--quiet

Med add, undertryck återkopplingsmeddelanden.

-v
--verbose

Med prune (beskär), rapportera alla borttagningar.

Med list, mata ut ytterligare information om arbetsträd (se nedan).

--expire <tid>

Med prune, beskär saknade arbetsträd bara om de är äldre än <tid>.

Med list, annotera saknade arbetsträd som beskärningsbara om de är äldre än <tid>.

--reason <sträng>

Med lock eller med add --lock, en förklaring till varför arbetsträdet är låst.

<arbetsträd>

Arbetsträd kan identifieras med hjälp av sökväg, antingen relativ eller absolut.

Om den sista sökvägskomponenten i arbetsträdets sökväg är unik bland arbetsträden kan den användas för att identifiera ett arbetsträd. Om du till exempel bara har två arbetsträd, vid /abc/def/ghi och /abc/def/ggg, så räcker ghi eller def/ghi för att peka på det förra arbetsträdet.

REFS

När man använder flera arbetsträd, delas vissa referenser mellan alla arbetsträd, men andra är specifika för ett enskilt arbetsträd. Ett exempel är HEAD, vilket är olika för varje arbetsträd. Det här avsnittet handlar om delningsreglerna och hur man kommer åt referenser för ett arbetsträd från ett annat.

Generellt sett är alla pseudoreferenser per arbetsträd och alla referenser som börjar med refs/ delas. Pseudoreferenser är sådana som HEAD, som ligger direkt under $GIT_DIR i stället för i $GIT_DIR/refs. Det finns dock undantag: referenser i refs/bisect, refs/worktree och refs/rewritten delas inte.

Referenser som är per arbetsträd kan fortfarande nås från ett annat arbetsträd via två speciella sökvägar, main-worktree och worktrees. Den förra ger åtkomst till referenser per arbetsträd för huvudarbetsträdet, medan den senare ger åtkomst till alla länkade arbetsträd.

Till exempel, main-worktree/HEAD eller main-worktree/refs/bisect/good upplöses till samma värde som huvudarbetsträdets HEAD respektive refs/bisect/good. På liknande sätt är worktrees/foo/HEAD eller worktrees/bar/refs/bisect/bad samma som $GIT_COMMON_DIR/worktrees/foo/HEAD och $GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad.

För att komma åt referenser är det bäst att inte titta direkt i $GIT_DIR. Använd i stället kommandon som git-rev-parse[1] eller git-update-ref[1], som hanterar referenser korrekt.

KONFIGURATIONSFIL

Som standard delas kodförrådets config-fil mellan alla arbetsträd. Om konfigurationsvariablerna core.bare eller core.worktree finns i den gemensamma konfigurationsfilen och extensions.worktreeConfig är inaktiverat, kommer de endast att tillämpas på huvudarbetsträdet.

För att få en arbetsträdsspecifik konfiguration kan du aktivera tillägget worktreeConfig, t.ex.:

$ git config extensions.worktreeConfig true

I det här läget lagras den specifika konfigurationen i sökvägen som anges av git rev-parse --git-path config.worktree. Konfiguration kan läggas till eller uppdateras i den här filen med git config --worktree. Äldre Git-versioner kommer att vägra åtkomst till kodförråd med det här tillägget.

Observera att i den här filen, är undantaget för core.bare och core.worktree borta. Om de finns i $GIT_DIR/config måste du flytta dem till config.worktree i huvudarbetsträdet. Du kan också ta tillfället i akt att granska och flytta annan konfiguration som du inte vill dela med alla arbetsträd:

  • core.worktree ska aldrig delas.

  • core.bare ska inte delas om värdet är core.bare=true.

  • core.sparseCheckout bör inte delas, såvida du inte är säker på att du alltid använder gles utcheckning för alla arbetsträd.

Se dokumentationen för extensions.worktreeConfig i git-config[1] för mer information.

DETALJER

Varje länkat arbetsträd har en privat underkatalog i kodförrådets katalog $GIT_DIR/worktrees. Namnet på den privata underkatalogen är vanligtvis basnamnet på det länkade arbetsträdets sökväg, eventuellt tillagt med ett nummer för att göra det unikt. Till exempel, när $GIT_DIR=/sökväg/main/.git skapar kommandot git worktree add /sökväg/annan/test-next next det länkade arbetsträdet i /sökväg/annan/test-next och skapar även en $GIT_DIR/worktrees/test-next-katalog (eller $GIT_DIR/worktrees/test-next1 om test-next redan är upptaget).

Inom ett länkat arbetsträd är $GIT_DIR inställt att peka till denna privata katalog (t.ex. /sökväg/main/.git/worktrees/test-next i exemplet) och $GIT_COMMON_DIR är inställt att peka tillbaka till huvudarbetsträdets $GIT_DIR (t.ex. /sökväg/main/.git). Dessa inställningar görs i en .git-fil som finns i den översta katalogen i det länkade arbetsträdet.

Sökvägsupplösning via git rev-parse --git-path använder antingen $GIT_DIR eller $GIT_COMMON_DIR beroende på sökvägen. Till exempel, i det länkade arbetsträdet returnerar git rev-parse --git-path HEAD /sökväg/main/.git/worktrees/test-next/HEAD (inte /sökväg/annan/test-next/.git/HEAD eller /sökväg/main/.git/HEAD) medan git rev-parse --git-path refs/heads/master använder $GIT_COMMON_DIR och returnerar /sökväg/main/.git/refs/heads/master, eftersom referenser delas mellan alla arbetsträd, förutom refs/bisect, refs/worktree och refs/rewritten.

Se gitrepository-layout[5] för mer information. Tumregeln är att inte göra några antaganden om huruvida en sökväg tillhör $GIT_DIR eller $GIT_COMMON_DIR när du behöver komma åt något direkt i $GIT_DIR. Använd git rev-parse --git-path för att få den slutliga sökvägen.

Om ett länkat arbetsträd flyttas manuellt måste gitdir-filen i postens katalog. Om till exempel ett länkat arbetsträd flyttas till /nysökväg/test-next och dess .git-fil pekar på /sökväg/main/.git/worktrees/test-next, ska /sökväg/main/.git/worktrees/test-next/gitdir uppdateras så att den i stället refererar till /nysökväg/test-next. Ännu bättre, kör git worktree repair för att återupprätta anslutningen automatiskt.

För att förhindra att en $GIT_DIR/worktrees-post beskärs (vilket kan vara användbart i vissa situationer, till exempel när postens arbetsträd lagras på en portabel enhet), använd kommandot git worktree lock, vilket lägger till en fil med namnet locked i postens katalog. Filen innehåller orsaken i klartext. Om till exempel ett länkat arbetsträds .git-fil pekar på /sökväg/main/.git/worktrees/test-next, kommer en fil med namnet /sökväg/main/.git/worktrees/test-next/locked att förhindra att test-next-posten beskärs. Se gitrepository-layout[5] för mer information.

När extensions.worktreeConfig är aktiverat, läses konfigurationsfilen .git/worktrees/<id>/config.worktree efter .git/config.

LIST UTMATNINGS-FORMAT

Kommandot worktree list har två utdataformat. Standardformatet visar detaljerna på en enda rad med kolumner. Till exempel:

$ git worktree list
/sökväg/till/bar-källa                (bare)
/sökväg/till/länkat-arbetsträd        abcd1234 [master]
/sökväg/till/annat-länkat-arbetsträd  1234abc  (detached HEAD)

Kommandot visar även anteckningar för varje arbetsträd, beroende på dess tillstånd. Dessa anteckningar är:

  • locked, om arbetsträdet är låst.

  • prunable, om arbetsträdet kan beskäras via git worktree prune.

$ git worktree list
/sökväg/till/länkat-arbetsträd      abcd1234 [master]
/sökväg/till/låst-arbetsträd        acbd5678 (brancha) locked
/sökväg/till/beskärbart-arbetsträd  5678abc  (detached HEAD) prunable

För dessa annoteringar, kan det också finnas en orsak, och detta kan ses med hjälp av utförligt-läget (verbose). Annoteringen flyttas sedan till nästa indragna rad följt av den ytterligare informationen.

$ git worktree list --verbose
/sökväg/till/länkat-arbetsträd                abcd1234 [master]
/sökväg/till/länkat-arbetsträd-ej-anlending   abcd5678 (detached HEAD) locked
/sökväg/till/länkat-arbetsträd-med-anlending  1234abcd (brancha)
        locked: arbetsträdssökvägen är monterad på en portabel enhet
/sökväg/till/prunable-worktree                5678abc1 (detached HEAD)
        prunable: ”gitdir”-filen pekar på en ickeexisterande plats

Observera att anteckningen flyttas till nästa rad om den ytterligare informationen är tillgänglig, annars stannar den kvar på samma rad som själva arbetsträdet.

porcelain-format

porcelain-formatet har en rad per attribut. Om -z anges avslutas raderna med NUL snarare än en nyrad. Attribut listas med en etikett och ett värde separerade med ett enda mellanslag. Booleska attribut (som bare och detached) listas endast som en etikett, och finns endast om värdet är sant. Vissa attribut (som locked) kan listas endast som en etikett eller med ett värde beroende på om en orsak finns tillgänglig. Det första attributet i ett arbetsträd är alltid worktree, en tom rad indikerar slutet på posten. Till exempel:

$ git worktree list --porcelain
worktree /sökväg/till/bar-källa
bare

worktree /sökväg/till/länkat-arbetsträd
HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
branch refs/heads/master

worktree /sökväg/till/annat-länkat-arbetsträd
HEAD 1234abc1234abc1234abc1234abc1234abc1234a
detached

worktree /sökväg/till/länkat-arbetsträd-låst-ingen-anledning
HEAD 5678abc5678abc5678abc5678abc5678abc5678c
branch refs/heads/locked-no-reason
locked

worktree /sökväg/till/länkat-arbetsträd-låst-med-anledning
HEAD 3456def3456def3456def3456def3456def3456b
branch refs/heads/locked-with-reason
locked anledningen till att den är låst

worktree /sökväg/till/beskärbart-arbetsträd
HEAD 1233def1234def1234def1234def1234def1234b
detached
prunable ”gitdir”-filen pekar på en ickeexisterande plats

Om inte -z används citeras alla "ovanliga" tecken i låsorsaken, såsom nyradstecken, och hela orsaken citeras enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]). Till exempel:

$ git worktree list --porcelain
...
locked "orsaken\nvarför är låst"
...

EXEMPEL

Mitt i ett refaktoreringspass kommer chefen in och kräver att något åtgärdas omedelbart. Vanligtvis används git-stash[1] för att tillfälligt lagra ändringar, men arbetsträdet är i ett sådant tillstånd av oordning (med nya, flyttade och borttagna filer, och andra småsaker utspridda) att det är olämpligt att riskera att störa något av det. I stället skapas ett tillfälligt länkat arbetsträd för att göra nödåtgärden, det tas bort när det är klart och därefter återupptas det tidigare refaktoreringspasset.

$ git worktree add -b kritisk-fix ../temp master
$ pushd ../temp
# ... hack hack hack ...
$ git commit -a -m 'nödlösning för chefen'
$ popd
$ git worktree remove ../temp

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:

worktree.guessRemote

Om ingen gren anges och varken -b, -B eller --detach används, skapar git worktree add som standard en ny gren från HEAD. Om worktree.guessRemote är satt till sant, försöker worktree add hitta en fjärrspårad gren vars namn unikt matchar det nya grennamnet. Om en sådan gren finns, checkas den ut och sätts som "uppströms" för den nya grenen. Om ingen sådan matchning kan hittas, återgår den till att skapa en ny gren från den aktuella HEAD.

worktree.useRelativePaths

Länka arbetsträd med relativa sökvägar (när "true") eller absoluta sökvägar (när "false"). Detta är särskilt användbart för inställningar där kodförrådet och arbetsträden kan flyttas mellan olika platser eller miljöer. Standardvärdet är "false".

Observera att om du ställer in worktree.useRelativePaths till "true" aktiveras konfigurationen extensions.relativeWorktrees (se git-config[1]), vilket gör den inkompatibel med äldre versioner av Git.

BUGGAR

Flera utcheckningar är generellt sett fortfarande experimentella, och stödet för undermoduler är ofullständigt. Det rekommenderas INTE att göra flera utcheckningar av ett superprojekt.

GIT

En del av git[1]-sviten