Hoppa till innehåll
September 9, 2026

Git worktrees: isoleringslagret för parallella AI-agenter

Ett Git-worktree är en extra arbetskatalog kopplad till ett befintligt Git-arkiv. Den har sin egen utcheckade gren, sitt eget index och sina egna ospårade filer, men delar objektarkiv, referenser och konfiguration med huvudarkivet. För parallella AI-kodningsagenter är detta den ideala isoleringsenheten: varje agent får en katalog som ingen annan process skriver till, dess commits hamnar på en gren som ingen annan checkat ut, och att skapa katalogen är en blixtsnabb utcheckning snarare än en tung kloning eller container-start. Denna artikel förklarar hur worktrees fungerar, varför de slår delade arbetskataloger, vilka problem som kan uppstå och hur Ivy Tendril automatiskt skapar ett worktree per plan och raderar det efter merge.

Vad ett worktree är

Varje Git-arkiv har som standard en arbetskatalog. Med git worktree add kan du koppla till fler. Varje katalog är en komplett utcheckning där du kan köra cd, redigera filer, köra byggen och göra commits.

# Skapa ett worktree en katalog upp, på en ny gren
git worktree add ../feature-x -b feature-x

# Lista alla worktrees för detta arkiv
git worktree list
# /Users/dev/app             a1b2c3d [main]
# /Users/dev/feature-x       a1b2c3d [feature-x]

Den nya katalogen innehåller en .git-fil, inte en .git-katalog. Filen pekar tillbaka till huvudarkivets .git/worktrees/feature-x, som hanterar index och HEAD för det specifika trädet. Objekt, referenser, Git-hooks och konfigurationer läses direkt från huvudarkivet. En commit gjord i ../feature-x syns omedelbart från huvudkatalogen via git log feature-x utan något behov av push eller fetch.

Två viktiga regler följer av denna arkitektur: En gren kan endast vara utcheckad i ett enda worktree åt gången; Git vägrar skapa två worktrees på samma gren. Dessutom bör worktree-katalogen placeras utanför huvudkatalogen så att den inte misstas för ospårade filer.

Varför worktrees slår delade kataloger för agenter

En kodningsagent läser och skriver filer, kör tester och skapar commits. Om två agenter gör detta i samma katalog uppstår en rörig blandning av ändringar, och testerna kan inte isolera en enskild agents arbete. Alternativen är en separat klon per agent, en Docker-container per agent eller ett worktree per agent.

Metod Eget filträd & gren Delat objektarkiv Startkostnad Körtidsisolering
Delad arbetskatalog Nej Ja Ingen Ingen
Separat klon per agent Ja Nej (full kopia) Full kloning + beroendeinstallation Ingen
Container per agent Ja Nej (om inte monterad) Image-pull + container-start Ja
Worktree per agent Ja Ja Blixtsnabb utcheckning Ingen

Ett worktree ger agenten precis vad den behöver för teknisk korrekthet (ett privat filträd och en privat gren) utan den tunga overheaden av runtime-isolering. Eftersom objektarkivet delas kostar ett projekt med åratal av historik endast utcheckningen av det aktuella trädet. Paketcache för verktyg som pnpm, Cargo och NuGet delas naturligt via användarens hemkatalog.

Containers förblir rätt val när agenter behöver installera systempaket eller binda nätverksportar. Metoderna utesluter inte varandra: ett worktree kan monteras in i en container. För vanliga kodningsuppgifter räcker ett rent worktree utmärkt.

Läs även mönster för agent-orkestrering för att förstå hur isolering samverkar med resten av utvecklingsflödet.

Felkällor och hur du undviker dem

Worktrees löser fil- och katalogkollisioner. De löser dock inte av sig själva tre andra utmaningar som kräver tydliga regler.

1. Två agenter som redigerar samma filer på olika grenar

Worktrees isolerar kataloger, inte avsikter. Om två planer ändrar auth/session.ts kommer båda grenarna att kunna committas utan problem, men den andra grenen som ska slås samman kommer att orsaka en merge-konflikt. Detta ska fångas redan vid planeringen: identifiera vilka moduler som berörs och schemalägg planerna sekventiellt eller dela upp dem så att varje plan äger sin modul.

2. Ocommittade ändringar (Dirty Trees)

Om en agent avbryts i förtid eller om en testkörning genererar temporära filer lämnas ospårade ändringar kvar. git worktree remove vägrar radera ett träd med ocommittade ändringar. En stabil orkestrerare sparar alla ändringar som agenten skapat på dess gren, så att ingenting går förlorat och granskaren har full insyn innan trädet tas bort.

# Inspektera innan borttagning
git -C ../feature-x status --short

# Ta bort ett rent worktree
git worktree remove ../feature-x

# Tvinga borttagning vid behov
git worktree remove --force ../feature-x

3. Bortglömda worktrees

Worktrees som skapas manuellt glöms lätt bort. Varje träd låser en gren och upptar diskutrymme. Om en katalog tas bort med rm -rf istället för git worktree remove sparar Git gamla poster i .git/worktrees/.

# Se vad som kan rensas
git worktree prune --dry-run --verbose

# Rensa inaktuella referenser
git worktree prune

Regeln är enkel: det system som skapar ett worktree måste också ansvara för att ta bort det vid en definierad punkt i uppgiftens livscykel.

Hur Ivy Tendril tillämpar worktrees

Ivy Tendril är en lokal-först skrivbordsapplikation (macOS, Windows, Linux) som driver kodningsagenter från plan till godkänd pull request. Worktrees är dess primära exekveringsenhet. Se produktöversikten och livscykelguiden.

  • Ett worktree per plan: När en plan godkänns skapar Tendril automatiskt ett eget worktree och en gren. Många planer körs samtidigt utan att main-grenen påverkas.
  • Verifiering i worktreet: Tester och diff beräknas uteslutande mot planens eget träd. Review-vyn visar diff och testrapporter sida vid sida.
  • Automatisk städning: När pull requesten slås samman raderas worktreet automatiskt.
  • Agentoberoende: Agenten kan vara Claude Code, Codex CLI, Copilot CLI, Gemini CLI eller OpenCode.
  • Helt lokalt: Worktrees, kod, planer och loggar stannar på din lokala dator. Se lokal-först AI-utveckling.

Kom igång med Ivy Tendril

Upptäck kraften i parallella AI-agenter med full isolering:

Written by

Ivy Team