Vill du låta Claude och Codex arbeta med samma app utan att skriva över varandras filer? Git-worktrees ger varje session en egen arbetskopia och gren. Det här följer upp min guide till två Claude-konton på en Mac: konton skiljer inloggningar åt, worktrees skiljer kodmappar åt. De löser olika problem.
Vad en worktree skiljer åt
En worktree är en extra arbetskopia kopplad till samma Git-repository. Varje kopia har egna filer och en egen gren, men delar commit-historiken. Då kan två agenter redigera oberoende av varandra. Inloggningsuppgifter, miljövariabler, databaser, tjänster som körs och driftsättningsmål blir inte separerade. Se det som en arbetsyta för källkod, inte som en säkerhetsgräns. En gren är inte heller en automatisk release: driftsättningen följer fortfarande din vanliga process.
Skapa rena utgångspunkter
Du behöver ett Git-repository och Git installerat. Kontrollera status och granska alla ändringar. Committa bara den avsedda gemensamma basen och lägg till uttryckliga sökvägar; stage:a inte allt på måfå. Exemplen utgår från HEAD, så ocommittat arbete följer inte med till de nya arbetskopiorna.
git status --short
git worktree add -b ai/ui ../my-app-ui HEAD
git worktree add -b ai/backend ../my-app-backend HEAD
Kontrollera sedan worktree-listan och båda mapparna. Git delar repositoryhistoriken, men projektmiljön kan saknas: beroenden, ignorerade filer, byggcachar och lokala inställningar behöver hanteras i varje arbetskopia. Använd godkända utvecklingsuppgifter och testdata; kopiera aldrig produktionshemligheter automatiskt. Ge samtidiga servrar olika portar och använd separata testdatabaser eller scheman och fixture-ID:n om båda skriver data. Några lokala processer eller en mocktjänst kan räcka; du behöver inte containerisera hela stacken.
Öppna verktyget i rätt mapp
Använd UI-mappen som Git skapade för Claude Code och backendmappen för Codex. Öppna dem som separata lokala projekt och kontrollera arbetskatalogen innan du fördelar uppgifter. Båda verktygen ska redan vara installerade och inloggade.
Båda verktygen erbjuder också hanterade worktree-flöden (Claude, Codex). Använd dem som alternativ till manuellt skapade mappar, utan att skapa en andra worktree för samma uppgift.
Enas om gränssnittet innan arbetet delas upp
Välj uppgifter som kan gå framåt var för sig. Claude kan till exempel äga UI-grenen och bygga en vy och en API-klient; Codex får backendgrenen och implementerar endpointen. Bestäm metod och sökväg, fält för begäran och svar, autentisering, valideringsfel och en test-fixture innan ni börjar. Varje agent äger en worktree; utse också en tydlig ägare för delade filer.
- Claude · UI-gren
- Överenskommet API-avtal
- Codex · backendgren
- Granska och integrera
Separata mappar skyddar filändringarna; det överenskomna svaret håller funktionens båda delar i linje.
Ett konkret fel: gränssnittet läser items, medan endpointen returnerar results. Git kan slå ihop ändringarna utan textkonflikt, men funktionen går ändå sönder. Bestäm svarens struktur innan arbetet delas upp och kontrollera båda implementationerna.
Granska, integrera och städa sedan
- Granska varje diff. Kontrollera ändrade filer, konfiguration, migreringar och dataåtkomst. Kör kontroller som täcker det överenskomna beteendet; agentens besked om att den är klar är inget bevis.
- Integrera en gren i taget. Integrera en granskad gren och kör relevanta kontroller, sedan den andra. Testa gränssnittet mot den riktiga ändpunkten när båda finns på plats.
- Kontrollera beteendet, inte bara Git. En konfliktfri sammanslagning hittar inte olika fältnamn, autentiseringsregler eller antaganden om delade tjänster. Testa gränsen med fixturen.
Granskningen kräver samma omdöme som att granska AI-genererad appkod eller organisera ett programmeringsteam: tydligt ägarskap hjälper, men en människa behöver kontrollera helheten.
Kontrollera status och de senaste commitarna i varje arbetskopia innan du städar, och bekräfta vad som redan har integrerats. Lista worktrees och ta bara bort den avsedda, färdiga sökvägen; låt Git skydda ocommittat arbete. Använd inte rm -rf eller tvångsborttagning som rutin.
För en app som närmar sig release granskar vår kodgranskning arkitektur, kritiskt beteende, datagränser och releaseunderlag utifrån produktens faktiska omfattning.