Claude Code worktrees: parallel werken zonder elkaars code te raken

Twee Claude Code-sessies in dezelfde projectmap kunnen elkaar behoorlijk in de weg zitten. De ene verplaatst een functie terwijl de andere haar nog probeert aan te passen. Je ziet daarna wel gewijzigde bestanden, maar moeilijker welke taak bij welke wijziging hoort.

Een Git-worktree geeft iedere taak een eigen werkmap met een eigen branch. Dat lost de directe bestandsbotsing op. Het is nog geen afspraak over hoe de twee oplossingen straks samen moeten werken. Juist die tweede helft verdient aandacht als je parallel wilt bouwen.

Volgens de Git-documentatie kun je meerdere werkmappen aan dezelfde repository koppelen. Ze delen Git-geschiedenis, maar hebben hun eigen uitgecheckte bestanden en eigen index. Je kunt daardoor verschillende branches tegelijkertijd open hebben.

Zie een branch als een lijn met wijzigingen en een worktree als de fysieke werkplek waar je aan zo’n lijn werkt. Een tweede terminalvenster maakt op zichzelf geen tweede werkplek. Openen beide vensters dezelfde map, dan lezen en schrijven ze dezelfde bestanden.

Een worktree is ook geen afzonderlijke computer. Processen, poorten en externe systemen zijn daarmee niet vanzelf gescheiden. Ik zou het daarom gebruiken als bestandsisolatie binnen een groter werkproces, met expliciete afspraken voor alles wat buiten die bestanden ligt.

De Claude Code-documentatie voor worktrees beschrijft deze CLI-route vanuit een bestaande Git-repository met minstens één commit:

Een tweede terminal kan een andere naam gebruiken:

Standaard ontstaan de mappen onder .claude/worktrees/ met branches die beginnen met worktree-. Controleer voor elke sessie de getoonde map en branch. Gebruikt je organisatie een geregistreerde startprocedure, volg dan die route in plaats van daarnaast eigen werkmappen te maken.

Kies de startcommit bewust. Als beide taken voortbouwen op dezelfde goedgekeurde basis, kun je hun resultaten later begrijpen. Start één taak op half werk van een andere taak, dan heb je een afhankelijkheid gemaakt die je bij integratie moet behouden.

Ik zou voor iedere taak drie dingen vastleggen: welke bestanden zij mag wijzigen, welk gedrag zij oplevert en wie de integratie doet. Vooral gedeelde bestanden vragen één eigenaar. Denk aan dependencybestanden, gedeelde types en de volgorde van databasemigraties.

Geen tekstconflict betekent nog geen correct geheel. Twee wijzigingen kunnen probleemloos samenvoegen terwijl het ene scherm een veld verwacht dat het andere heeft verwijderd. Dat is een inhoudelijk conflict. De afbakening moet dus verder gaan dan bestandsnamen.

Stel dat een interne kennisbank een duidelijkere melding bij een lege zoekopdracht nodig heeft. Tegelijk moet de gebruikershandleiding uitleggen hoe collega’s zoeken. Je wilt beide taken apart laten uitwerken.

Taak A krijgt het zoekscherm en de bijbehorende tests. Gewenst gedrag: alleen spaties leveren een melding op zonder zoekverzoek. Taak B krijgt uitsluitend de handleiding. De exacte melding en het gedrag spreek je vooraf af, zodat de schrijver niets hoeft te raden. Beide vertrekken vanaf dezelfde basis.

Laat A geen algemene zoekbibliotheek vervangen en B geen schermtekst in code aanpassen. Heeft B tijdens het schrijven een beter voorstel voor de melding, dan meldt die dat aan de integratie-eigenaar. De eigenaar beslist en verwerkt de wijziging op één plek. Anders gaan beide taken alsnog aan hetzelfde contract trekken.

De twee sessies kunnen elk hun eigen lokale tests of documentcontrole doen. Als beide een ontwikkelserver nodig hebben, moet je de poorten scheiden. Gebruiken ze een gedeelde database, dan moet je ook voorkomen dat een reset of test van A de gegevens van B verandert.

Voor integratie landt eerst het gedrag van A. Controleer daarna de tekst van B tegen de werkelijke interface. Bekijk of de handleiding precies de melding en vervolgstap beschrijft die nu bestaan. De tweede taak wordt zo op het geïntegreerde resultaat beoordeeld, in plaats van alleen op haar oorspronkelijke uitgangspunt.

De workflowdocumentatie laat zien hoe afzonderlijke worktrees parallelle sessies ondersteunen. Mijn advies voor afronding: laat één eigenaar bepalen in welke volgorde de wijzigingen naar de doelbranch gaan.

Lees per taak de diff en uitgevoerde controles. Werk na de eerste integratie de tweede branch bij volgens de Git-afspraken van je project. Los conflicten op met kennis van beide bedoelingen. “Neem mijn versie” is geen inhoudelijke afweging als de andere taak ondertussen gewenst gedrag toevoegde.

Herhaal daarna de controles die door de combinatie geraakt worden. Losse groene tests bewijzen alleen hun eigen versie. Voor de kennisbank betekent integratiecontrole: zoeken met lege en normale invoer, plus de handleiding nalopen op overeenstemming. Bij een gedeeld API-contract horen ook de afnemers in die controle.

Bij het verlaten van een interactieve worktreesessie controleert Claude Code de staat en kan het vragen of je de map wilt bewaren of verwijderen. Lees dat voorstel: bewaren en verwijderen zijn verschillende beslissingen. Kies bewaren zolang er nog werk in zit dat niet veilig is vastgelegd.

Controleer vóór opruimen dat het resultaat op de bedoelde plek beschikbaar is en er geen proces meer uit de map draait. Een geslaagde taak hoeft geen vergeten werkmap te worden. Leg ook vast wat nog openstaat als integratie niet afgerond is.

Ben je nog bezig met je eerste enkele taak, gebruik dan eerst onze Claude Code-handleiding. In de Vibe Coding Training kun je oefenen met het afbakenen en controleren van wijzigingen. Parallel werk wordt pas overzichtelijk als iedere taak zelfstandig begrijpelijk blijft.