Worktree: meerdere versies van je code tegelijk openen
Stel je voor dat je aan een groot verbouwingsproject werkt en je wilt tegelijkertijd twee ontwerpen uitproberen: één met een uitbouw en één zonder. Normaal zou je steeds je hele huis moeten ombouwen om van het ene naar het andere ontwerp te wisselen. Een worktree is te vergelijken met het bouwen van een tweede, tijdelijke kopie van je huis ernaast, die dezelfde fundering en bouwtekeningen deelt, maar waarin je onafhankelijk kunt verbouwen zonder het origineel aan te raken.
In de softwarewereld is een worktree een functie van Git, het populairste systeem voor versiebeheer (het bijhouden van alle wijzigingen in broncode over de tijd). Met `git worktree` kan een programmeur meerdere versies of vertakkingen ("branches") van dezelfde programmeercode tegelijk als aparte mappen op zijn computer openen, zonder dat hij de hoofdrepository (de centrale opslagplaats van de code) hoeft te dupliceren. Dat scheelt tijd, schijfruimte en het voortdurend wisselen tussen taken. De laatste jaren duikt de term ook op in een heel andere context: kunstmatige-intelligentie-assistenten die zelfstandig code schrijven, gebruiken worktrees om meerdere AI-agents tegelijk en onafhankelijk van elkaar aan dezelfde codebase te laten werken.
Wat is het precies?
Om worktree te begrijpen, moet je eerst weten hoe Git normaal werkt. Een Git-repository bestaat uit twee delen: een verborgen map genaamd .git, waarin de volledige geschiedenis en alle versies van het project zijn opgeslagen, en een "working directory" (werkmap): de zichtbare bestanden waarin je daadwerkelijk programmeert. Normaal gesproken heb je één werkmap per repository. Wil je aan een andere branch werken, dan moet je "switchen" (met het commando git checkout of git switch), waarbij Git de bestanden in je werkmap vervangt door die van de andere branch.
Een worktree doorbreekt die één-op-één-relatie. Met git worktree add maak je een extra werkmap aan, ergens anders op je schijf, die is gekoppeld aan dezelfde .git-map. Beide werkmappen delen dus dezelfde geschiedenis en dezelfde opgeslagen bestandsversies (de zogeheten objectdatabase), maar hebben ieder hun eigen actieve branch en hun eigen bestanden op schijf. Je kunt in de ene map dus rustig aan een nieuwe functie bouwen, terwijl in de andere map de stabiele versie van de software klaarstaat om te testen of te draaien.
Er is één belangrijke beperking: dezelfde branch kan niet tegelijk in twee worktrees zijn uitgecheckt. Git houdt dat tegen om te voorkomen dat je per ongeluk conflicterende wijzigingen op dezelfde vertakking maakt. Verwijderen doe je met git worktree remove, waarna de extra map verdwijnt maar de gedeelde geschiedenis in .git intact blijft.
Wat wil men ermee bereiken?
Het kerndoel van worktree is efficiëntie: minder tijd kwijt zijn aan het wisselen van context. Zonder worktree moet een ontwikkelaar die snel een bug wil oplossen op de hoofdbranch, eerst zijn huidige, onafgemaakte werk opslaan ("stashen") voordat hij kan wisselen, en dat werk daarna weer terughalen. Bij grote projecten kan dat wisselen ook kostbaar zijn omdat Git dan duizenden bestanden opnieuw moet neerzetten en bouwsystemen (compilers, testrunners) alles opnieuw moeten verwerken.
Met een worktree hoeft dat niet: je opent gewoon een tweede terminalvenster of code-editor in de andere map en werkt door, terwijl je eerste werk ongemoeid blijft staan. Dat is vooral waardevol bij langlopende taken zoals het compileren van grote programma's, het draaien van langdurige tests, of het parallel onderhouden van een oude, ondersteunde softwareversie naast de nieuwste ontwikkelversie.
Een nieuwere ambitie, die de term relevant maakt voor een site over toekomsttechnologie, is het mogelijk maken van parallelle AI-agents. Als een AI-programmeerassistent zelfstandig code mag aanpassen, wil je vaak dat meerdere van die assistenten tegelijk aan verschillende taken werken zonder elkaars bestanden te verstoren. Worktrees bieden daarvoor een natuurlijke, isolerende structuur: iedere agent krijgt zijn eigen werkmap en dus zijn eigen "kamer" binnen dezelfde gedeelde geschiedenis.
Voorbeelden uit de praktijk
Het commando git worktree zelf werd toegevoegd aan Git in juli 2015, met de release van Git 2.5. De functie is destijds voornamelijk ontwikkeld door de Vietnamese Git-bijdrager Nguyễn Thái Ngọc Duy, die al langer werkte aan manieren om Git-repositories flexibeler en zuiniger met schijfruimte te laten omgaan.
Git gebruikt zijn eigen worktree-functie ook om zijn eigen broncode te onderhouden: de Git-ontwikkelaars werken vaak met meerdere worktrees om tegelijk te werken aan de ontwikkelversie, aan beveiligingsfixes voor oudere ondersteunde versies, en aan het testen van bijdragen van anderen, zonder telkens te hoeven wisselen.
In de wereld van geautomatiseerde software-integratie ("continuous integration" of CI) gebruiken bouwsystemen zoals de Git-plugin van Jenkins worktrees om meerdere builds van dezelfde repository parallel en geïsoleerd te laten draaien, zonder dat elke build een volledige nieuwe kopie van de repository hoeft te downloaden.
Recenter, in 2024 en 2025, is worktree een terugkerend onderwerp geworden rond AI-codeerassistenten. Ontwikkelaars die tools zoals Anthropics Claude Code gebruiken, passen worktrees toe om meerdere AI-sessies tegelijk op verschillende branches van hetzelfde project te laten werken: de ene sessie repareert bijvoorbeeld een bug, terwijl een andere sessie parallel een nieuwe functie bouwt, allemaal binnen dezelfde repository maar in gescheiden mappen. Dit patroon wordt inmiddels ook in documentatie en community-gidsen van andere AI-programmeertools als aanbevolen werkwijze genoemd.
Hoe ver is de techniek?
Als Git-functie is worktree volwassen en stabiel: het bestaat al meer dan tien jaar, is onderdeel van de standaard Git-installatie op vrijwel elk besturingssysteem, en wordt breed ondersteund door ontwikkelomgevingen. Er zijn sindsdien geen ingrijpende wijzigingen geweest; de ontwikkeling bestaat vooral uit kleine verbeteringen, zoals betere ondersteuning voor submodules (deelrepositories binnen een project) en duidelijkere foutmeldingen.
De echte ontwikkeling zit op dit moment niet in de Git-functie zelf, maar in hoe worktrees worden ingezet binnen nieuwere workflows, zoals AI-agentplatforms. Daar is de techniek nog volop in beweging: er bestaat geen gestandaardiseerde manier waarop AI-tools worktrees beheren, en verschillende leveranciers experimenteren met eigen oplossingen voor het opruimen van oude worktrees, het samenvoegen van resultaten van parallelle agents, en het voorkomen van conflicten wanneer meerdere agents toch dezelfde bestanden raken. Dit is dus eerder een organisatorisch en gereedschapsvraagstuk dan een technische doorbraak die nog moet komen.
Een reële beperking blijft dat elke worktree evenveel schijfruimte voor de uitgecheckte bestanden gebruikt als een normale werkmap (al delen ze de onderliggende geschiedenis). Bij zeer grote projecten met veel gegenereerde bestanden kan het gebruik van veel worktreesTegelijk daardoor alsnog fors schijfruimte kosten.
Wie werken eraan?
Git is een open source-project zonder één bedrijf als eigenaar. De huidige hoofdonderhouder is Junio Hamano, die het project al sinds 2005 leidt, kort na de oprichting door Linux-bedenker Linus Torvalds. Bijdragen komen van een wereldwijde gemeenschap van vrijwilligers en van betaalde ontwikkelaars bij grote techbedrijven.
Rond Git bouwen enkele grote spelers commerciële platforms en tooling: GitHub (sinds 2018 onderdeel van Microsoft), GitLab, en Atlassian (met Bitbucket). Deze bedrijven ondersteunen worktree-achtige workflows vooral indirect, via documentatie en integraties met code-editors, eerder dan met eigen uitbreidingen op het Git-commando zelf.
Op het gebied van AI-codeerassistenten die worktrees gebruiken voor parallelle agents, is Anthropic (maker van Claude Code) een van de zichtbare partijen, naast andere aanbieders van AI-programmeertools die vergelijkbare patronen toepassen. Dit is een relatief jong en versnipperd veld zonder duidelijke marktleider in hoe worktrees daarbinnen precies worden benut.