Je bent halverwege een nieuw API-endpoint. De code compileert, de tests zijn groen, en Claude Code heeft volledige context van wat je aan het doen bent. Dan licht Slack op: een productie-bug die nu gefixt moet worden.

Dus stash je je wijzigingen. Switch je van branch. Probeer je te herinneren hoe de codebase eruitzag vóór je feature-werk. Fix de bug. Switch terug. Pop de stash. Leg opnieuw aan Claude Code uit waar je mee bezig was.

Herkenbaar? Er is een betere manier.

Wat zijn git worktrees?

Een git worktree laat je meerdere branches van dezelfde repository uitchecken in aparte mappen — zonder de repo opnieuw te clonen. Elke map heeft zijn eigen working tree, zijn eigen branch, en zijn eigen bestanden. Maar ze delen dezelfde .git-history.

# Maak een worktree aan voor een hotfix
git worktree add ../mijn-project-hotfix fix/payment-timeout

Dat is alles. Je hebt nu twee mappen:

  • mijn-project/ — je hoofdkopie, nog steeds op je feature branch
  • mijn-project-hotfix/ — een aparte map, uitgecheckt op fix/payment-timeout

Geen clone. Geen download. Het duurt seconden omdat de bestanden al lokaal staan. De nieuwe map is een volledige werkkopie — je kunt er onafhankelijk in builden, testen en runnen.

Waarom worktrees en Claude Code zo goed bij elkaar passen

Claude Code draait in je terminal, in een specifieke map. Het leest de bestanden om zich heen, bouwt context op vanuit wat het ziet, en werkt binnen die scope. Eén map, één sessie, één focus.

Dat past perfect bij worktrees. Elke worktree is een aparte map met een aparte branch. Start een Claude Code-sessie in elk ervan, en je hebt onafhankelijke AI-sessies — elk met hun eigen context, hun eigen gesprek, hun eigen focus.

Geen bestandsconflicten. Geen stash-gegoochel. Geen opnieuw uitleggen waar je mee bezig was. Elke sessie pakt precies op waar die is.

Opzetten voor een .NET solution

Stel, je werkt aan een ASP.NET Core solution genaamd OrderSystem. Je hoofdkopie staat in ~/projects/OrderSystem/, en je zit op een feature branch.

Er komt een hotfix binnen. Dit doe je:

# Vanuit je hoofdmap
cd ~/projects/OrderSystem

# Maak een worktree aan voor de hotfix
git worktree add ../OrderSystem-hotfix fix/order-total-rounding

# Open een nieuw terminal-tabblad en navigeer ernaartoe
cd ~/projects/OrderSystem-hotfix

De worktree bevat je volledige solution — .sln-bestand, alle projecten, alle configuratie. Je kunt direct draaien:

dotnet build
dotnet test

Alles werkt. Het is een complete kopie van je repo, alleen op een andere branch.

Start nu Claude Code:

claude

Claude Code leest de solution-structuur, vindt de .csproj-bestanden, ziet de CLAUDE.md — en is klaar om te werken. Volledig onafhankelijk van je andere sessie.

Scenario: feature + hotfix tegelijkertijd

Zo werkt dit in de praktijk.

Terminal 1 — je feature-werk, in ~/projects/OrderSystem/:

Je bouwt een klantendashboard-endpoint. Claude Code helpt je al een uur. Het kent de controller-patronen, de service-laag, de DTO’s die je hebt aangemaakt. Je zit midden in een gesprek:

“Voeg paginering toe aan het GetOrderHistory-endpoint. Gebruik hetzelfde PagedResult-patroon als in de ProductsController.”

Claude Code werkt hieraan. Laat het met rust.

Terminal 2 — de hotfix, in ~/projects/OrderSystem-hotfix/:

Je opent een verse Claude Code-sessie:

“Er zit een afrondingsbug in OrderTotalCalculator.cs. Bij het toepassen van een procentuele korting komt het totaal soms uit op drie decimalen in plaats van twee. Fix het en voeg een unit test toe die dit edge case dekt.”

Deze sessie weet niets van je feature-werk. Dat hoeft ook niet. Het focust puur op de afrondingsbug, vindt het probleem, schrijft de fix, voegt de test toe.

Vijftien minuten later is de hotfix klaar. Je commit, pusht, maakt een PR aan. Ondertussen heeft Terminal 1 het paginering-werk afgerond — volledig ongestoord.

CLAUDE.md werkt automatisch mee

Als je een CLAUDE.md-bestand in je repository root hebt — en dat zou je moeten hebben — dan reist het mee met elke worktree. Wanneer Claude Code start in een worktree-map, vindt en leest het CLAUDE.md net zoals in je hoofdkopie.

Je projectconventies, architectuurnotities, codestandaarden — alles geldt automatisch. Je hoeft geen bestanden te kopiëren of iets in te stellen. De worktree is een echte checkout van je repository, dus alles wat in git wordt bijgehouden is er.

Opruimen

Als je klaar bent met een worktree, ruim je het op:

# Zorg eerst dat je je wijzigingen hebt gecommit en gepusht
cd ~/projects/OrderSystem-hotfix
git push origin fix/order-total-rounding

# Verwijder dan de worktree
cd ~/projects/OrderSystem
git worktree remove ../OrderSystem-hotfix

De map verdwijnt, de branch blijft. Je git-history is schoon, en je bent terug bij één werkmap.

Als je wilt zien welke worktrees er actief zijn:

git worktree list

Ik maak er een gewoonte van om worktrees op te ruimen zodra de branch is gemerged. Het houdt je schijf netjes en voorkomt verwarring over welke mappen nog actief zijn.

Wanneer worktrees overkill zijn

Laten we eerlijk zijn — je hebt dit niet altijd nodig.

Snelle fixes op dezelfde branch. Als je maar één bestand hoeft te bewerken en te committen, is git stash prima. Maak geen worktree aan voor een wijziging van twee minuten.

Sterk gekoppelde wijzigingen. Als beide taken dezelfde bestanden moeten aanpassen, helpen worktrees niet. Je krijgt toch merge conflicts. Werk er dan sequentieel aan.

Kleine repositories. Als je project een enkele API is met vijf bestanden, voegt het beheren van meerdere mappen meer complexiteit toe dan het wegneemt.

Worktrees schitteren wanneer je solution groot genoeg is dat verschillende taken verschillende delen van de codebase raken. Een typische .NET solution met meerdere projecten — API, services, shared libraries, tests — is precies waar deze aanpak rendeert.

Probeer het zelf

De volgende keer dat er een onderbreking komt terwijl je midden in een feature zit, weersta de drang om te stashen. Doe in plaats daarvan:

# Maak een worktree aan voor de onderbreking
git worktree add ../mijn-project-fix fix/het-urgente-ding

# Open een nieuwe terminal
cd ../mijn-project-fix
claude

Geef Claude Code een duidelijke, gerichte instructie. Laat het werken terwijl je andere sessie precies blijft waar je hem achterliet.

De eerste keer dat je terugschakelt naar je feature-terminal en alles precies aantreft zoals je het achterliet — context intact, gesprek bewaard, bestanden onaangeroerd — vraag je je af waarom je ooit git stash gebruikte.