Vil du la Claude og Codex arbeide på samme app uten å overskrive hverandres filer? Git-worktrees gir hver økt sin egen arbeidskopi og gren. Dette følger opp guiden min til to Claude-kontoer på én Mac: kontoer skiller innlogginger; worktrees skiller kildekodemapper. De løser ulike problemer.
Hva et worktree skiller
Et worktree er en ekstra arbeidskopi som er koblet til det samme Git-repositoriet. Hver kopi har egne filer og sin egen gren, men deler commit-historikken. Dermed kan to agenter redigere uavhengig. Innloggingsopplysninger, miljøvariabler, databaser, tjenester som kjører og utrullingsmål blir ikke skilt. Se det som et arbeidsområde for kildekode, ikke som en sikkerhetsgrense. En gren er heller ikke en automatisk lansering: utrulling skjer fortsatt gjennom den vanlige prosessen din.
Lag rene utgangspunkt
Du trenger et Git-repository og Git installert. Sjekk status og gå gjennom alle endringer. Commit bare den delte basen du har valgt, og legg til bestemte filstier; ikke stage alt ukritisk. Eksemplene starter fra HEAD, så ulagret arbeid blir ikke kopiert til de nye arbeidskopiene.
git status --short
git worktree add -b ai/ui ../my-app-ui HEAD
git worktree add -b ai/backend ../my-app-backend HEADSjekk deretter worktree-listen og begge mappene. Git deler repository-historikken, men prosjektoppsettet kan mangle: avhengigheter, ignorerte filer, byggebuffere og lokale innstillinger må håndteres i hver kopi. Bruk godkjente utviklingstilganger og testdata; kopier aldri produksjonshemmeligheter automatisk. Gi servere som kjører samtidig ulike porter, og bruk separate testdatabaser eller skjemaer og fixture-ID-er hvis begge skriver data. Noen lokale prosesser eller en mocktjeneste kan være nok; du trenger ikke å containerisere hele stakken.
Åpne verktøyet i riktig mappe
Bruk UI-mappen opprettet med Git til Claude Code og backendmappen til Codex. Åpne hver som sitt eget lokale prosjekt, og kontroller arbeidsmappen før du fordeler oppgaver. Begge verktøyene må allerede være installert og pålogget.
Begge verktøyene tilbyr også administrerte worktree-forløp (Claude, Codex). Bruk disse som alternativ til manuelt opprettede mapper, uten å lage en ekstra worktree for samme oppgave.
Avtal grensesnittet før dere deler arbeidet
Velg oppgaver som kan gå framover uavhengig. Claude kan for eksempel eie UI-grenen og bygge en skjerm og en API-klient; Codex får backendgrenen og implementerer endepunktet. Avtal metode og sti, felter for forespørsel og svar, autentisering, valideringsfeil og et test-fixture før dere begynner. Hver agent eier ett worktree; gi også delte filer en tydelig eier.
- Claude · UI-gren
- Avtalt API-kontrakt
- Codex · backendgren
- Gjennomgå og integrer
Separate mapper holder filendringene adskilt; den avtalte svarstrukturen holder begge delene på linje.
Et typisk problem: UI-et leser items, mens endepunktet returnerer results. Git kan slå sammen endringene uten en tekstkonflikt, selv om funksjonen fortsatt er ødelagt. Avtal svarstrukturen før arbeidet går parallelt, og kontroller begge implementasjonene.
Gjennomgå, integrer og rydd opp etterpå
- Se på hver diff. Kontroller endrede filer, konfigurasjon, migreringer og datatilgang. Kjør kontrollene som dekker den avtalte oppførselen; agentens beskjed om at den er ferdig, er ikke dokumentasjon.
- Integrer én gren om gangen. Integrer en gjennomgått gren og kjør relevante kontroller, deretter den andre. Test grensesnittet mot det faktiske endepunktet når begge er på plass.
- Kontroller oppførselen, ikke bare Git. En konfliktfri sammenslåing oppdager ikke ulike feltnavn, tilgangsregler eller antakelser om delte tjenester. Test grensesnittet med fixturet.
Denne gjennomgangen krever samme vurdering som å gå gjennom AI-generert appkode eller organisere et programmeringsteam: tydelig eierskap hjelper, men et menneske må fortsatt kontrollere den samlede oppførselen.
Før opprydding, sjekk status og de siste commitene i hver arbeidskopi og bekreft hva som allerede er integrert. Vis worktree-listen, og fjern bare den tiltenkte, ferdige banen; la Git beskytte ulagret arbeid. Ikke bruk rm -rf eller tvangsfjerning som rutine.
For en app som nærmer seg lansering gjennomgår vår kodeaudit arkitektur, kritisk oppførsel, datagrenser og lanseringsgrunnlag ut fra produktets faktiske omfang.