Git worktree: isolera AI-kod i en egen arbetskatalog

1. Kontrollera ditt nuvarande arbete

Du har ett pågående arbete i projektet ai-app och vill låta en agent rätta ett formulärfel. Börja med en inventering i originalkatalogen. Exemplen använder PowerShell och lokala sökvägar; byt dem mot dina egna. Kör ett block i taget och läs resultatet innan nästa steg. Guiden förutsätter ett vanligt Git-repository med minst en commit och utan submoduler.

Set-Location C:/projekt/ai-app
git --version
git status --short
git branch --show-current
git rev-parse HEAD
git worktree list

Spara commit-id, grennamn och status i dina arbetsanteckningar. Git status visar bland annat ändrade och ospårade filer. Om du har en halvfärdig rättning i originalet ska du först bestämma om den behövs som grund för agentens uppgift. Exemplet utgår från HEAD, alltså en commit, och tar inte med dina oincheckade ändringar.

Facit är att du kan peka ut startpunkten och förklara varje befintlig ändring. Du behöver inte städa bort ditt arbete för att följa exemplet. Undvik däremot att skapa worktreen från fel startpunkt och sedan be agenten rekonstruera sådant som bara finns i originalkatalogen.

2. Skapa en ny gren och en egen katalog

Välj ett nytt grennamn och en ledig katalog bredvid projektet. I exemplet heter grenen ai/formularfel och katalogen ai-app-agent. Enligt Git worktree-dokumentationen skapar add med -b en gren och checkar ut den i den nya katalogen. HEAD anges här uttryckligen som startpunkt.

git worktree add -b ai/formularfel ../ai-app-agent HEAD
if ($LASTEXITCODE -ne 0) { throw 'Worktreen kunde inte skapas' }
git worktree list
git -C ../ai-app-agent branch --show-current
git -C ../ai-app-agent rev-parse HEAD
git -C ../ai-app-agent status --short

Facit är två kataloger i listan, ai/formularfel i den nya och samma commit-id som du noterade. Den nya katalogens status ska vara tom. Om grennamnet redan finns väljer du ett annat namn. Använd inte -B eller force för att runda stoppet. Öppna sedan just ai-app-agent i editorn och kontrollera dess terminalkatalog innan du startar agenten.

Worktrees delar repositorydata, bland annat vanliga grenreferenser och normalt repositorykonfiguration, men har egna HEAD och index. De är därför inte två oberoende kloner. Git hindrar normalt samma gren från att vara utcheckad i två worktrees. Behåll separata grenar även när uppgifterna verkar små.

3. Bestäm miljö och beroenden innan agenten kör

En separat katalog är ingen säkerhetssandbox. Den begränsar inte i sig processens åtkomst till värddatorn eller externa tjänster. Git beskriver arbetskataloger och delad metadata, inte en behörighetsgräns. Git credentials beskriver dessutom autentisering via konfigurerade hjälpprogram. Utgå inte från att den nya katalogen får separata inloggningsuppgifter.

Gör därför ett konkret miljöbeslut: vilken testdatabas, vilka miljövariabler och vilken lokal port får agenten använda? Kopiera inte produktionshemligheter som en bekvämlighetsåtgärd. Om uppgiften kräver skydd mot kodens åtkomst till datorn, välj en separat begränsad körmiljö innan installation och test. Worktreen löser inte den delen.

Läs projektets instruktioner i den nya katalogen och välj dess pakethanterare. För ett npm-projekt finns guiden om npm ci och installationsprov. Bestäm hur installationen ska göras och vilka scripts du tillåter innan du kör dem. Dokumentera saknade beroenden i stället för att be agenten byta installationsmetod på måfå.

Ge agenten en avgränsad uppgift: rätta det angivna formulärfelet i ai-app-agent, beskriv berörda filer och kör den beslutade kontrollen. Be den lämna resultatet för granskning. Guiden om agenter och automatisering hjälper dig formulera arbetsgränserna.

4. Granska alla ändringar och kör projektets prov

Gå igenom resultatet själv i agentkatalogen. Git diff-dokumentationen skiljer mellan arbetsändringar och det som har lagts i index. Kontrollera båda. En tom vanlig diff räcker inte om agenten redan har stageat ändringen.

Set-Location C:/projekt/ai-app-agent
git status --short
git diff
git diff --cached
git diff --check
git diff --cached --check

Statuslistan behövs även för nya filer som ännu inte ingår i diffen. Öppna dem och kontrollera att uppdraget inte har fått extra funktioner, hemligheter eller genererade filer. Kontrollen med --check gäller konfliktmarkörer och whitespacefel; den avgör inte om formuläret fungerar.

Kör projektets dokumenterade test och bygge. För formulärexemplet bör du också prova den händelse som utlöste felet och ett normalt lyckat inskick. Spara de faktiska kommandona, exitkoderna och vad du såg. Om ett test saknas eller inte går att köra skriver du det i granskningsunderlaget. Facit är en begriplig diff och dokumenterade prov som täcker just uppgiften.

Kontrollera status igen efter proven. Lägg därefter endast granskade filer i index och skapa en commit. Filnamnen nedan är exempel; använd namnen från din verkliga statuslista.

git add -- src/formular.js tests/formular.test.js
git diff --cached
git commit -m "Rätta formulärets felhantering"
if ($LASTEXITCODE -ne 0) { throw 'Commit misslyckades' }
git status --short

5. Integrera den godkända ändringen

Följ projektets granskningsflöde om ändringar ska gå via pull request. I ett enkelt lokalt projekt kan du integrera efter godkänd granskning. Gå tillbaka till originalet och kontrollera att du är på den avsedda mottagargrenen. Om inventeringen visade eget arbete som finns kvar, spara och hantera det först; kör inte följande merge i det läget.

Set-Location C:/projekt/ai-app
git branch --show-current
git status --short
git merge --ff-only ai/formularfel
if ($LASTEXITCODE -ne 0) { throw 'Integrationen stoppade; granska historiken' }

Enligt Git merge tillåter ff-only en fast-forward och stoppar annars med felkod. Om mottagargrenen har fått annan historik behöver du ett nytt integrationsbeslut. Byt inte automatiskt till ett mer tillåtande kommando. Efter integrationen kör du relevanta prov i mottagarens miljö också, särskilt om miljöerna skiljer sig.

6. Ta bort katalogen och inspektera grenen

Avsluta agenten och stäng processer som använder katalogen. Kontrollera både normal status och ignorerade filer. Git status visar ignorerade filer med --ignored; leta särskilt efter lokala anteckningar, miljöfiler och testresultat som du vill spara utanför worktreen. Tom normal status bevisar inte att katalogen saknar sådant material.

git -C ../ai-app-agent status --short
git -C ../ai-app-agent status --short --ignored
git worktree remove ../ai-app-agent
if ($LASTEXITCODE -ne 0) { throw 'Borttagningen stoppade; undersök orsaken' }
git worktree list
git branch --list ai/formularfel

Worktree remove kräver normalt en ren worktree. Använd inte force om kommandot stoppar: undersök ändringarna och spara det du behöver. Facit efter lyckad borttagning är att katalogen inte längre finns i worktree-listan. Grenen kan du inspektera separat och behålla om du behöver den.

När arbetet är integrerat och grenen kan avvecklas använder du git branch -d ai/formularfel. Git branch-dokumentationen kräver för -d att grenen är fullt integrerad i upstream, eller HEAD om upstream saknas. Om borttagningen vägras, granska historiken och behåll grenen tills orsaken är förstådd. Den extra katalogen ska vara borta först när arbetsmaterialet är omhändertaget.