← Alle berichten

Elke worktree krijgt een eigen database

Ik doe bijna al mijn werk tegenwoordig in git worktrees. Zowel agentic coding als echte featureontwikkeling doe ik in een worktree, zodat alles wat ik doe los staat van andere werkstromen. Ik vind deze manier van werken handig, want ik kan met iets bezig zijn, het laten liggen en aan iets anders werken zonder te vertrappen wat ik ernaast open heb staan.

Wie had gedacht dat worktrees (een feature die ik al tien jaar negeer in git help) de killertechnologie van 2026 zouden worden.

Ken je worktrees niet, dan kun je er hier over lezen.

Er is één probleem. Worktrees klonen je code. Ze klonen niets wat niet in git is ingecheckt, en daar heb je er twee van nodig: je gitignored bestanden en een database. Dus elke worktree die je aanmaakt verbindt vrolijk met exact dezelfde lokale Postgres. Zodra één branch een migratie draait, is het schema veranderd waar de andere drie op leunen, en daar gaat mijn perfecte isolatie.

Dus schreef ik een kleine tool om dat op te lossen: wtdb.

Mijn setup ziet er zo uit:

  • main-repo/: volgt altijd origin/main, migraties draaien na elke pull. De schone referentiekopie.
  • main-repo-worktree-feat-blah-blah/: een worktree voor een featurebranch met een eigen database, plus cache en node_modules gekopieerd uit de hoofdrepo.
  • main-repo-worktree-feat-foo-bar/: een andere worktree voor een featurebranch met een eigen database, plus cache en node_modules gekopieerd uit de hoofdrepo.

Als ik een worktree toevoeg, haakt wtdb in op de post-checkout van git en doet het de drie saaie dingen die niemand met de hand regelt:

  1. Kloont de database. Het gebruikt CREATE DATABASE ... TEMPLATE van Postgres, dus je krijgt bijna meteen een kopie van je dev-data, geen dump-en-restore waarbij je koffie gaat halen.
  2. Kopieert je env-bestand en herschrijft de database-URL naar de nieuwe kopie.
  3. Kopieert de gitignored onderdelen die je echt nodig hebt. Dat zijn node_modules en dergelijke, met copy-on-write-clones, dus het kost je geen schijfruimte.

Nu kan ik een dev-server draaien tegen elke worktree en een agent in zijn eigen sandbox alle migraties en schemawijzigingen laten doen die hij wil.

Beginnen is één installatie en drie commando’s:

# Always check the source code of a new tool before installing it.
# I know this is a bad practice. I will make this available on homebrew soon. Maybe.
curl -fsSL https://raw.githubusercontent.com/willhackett/wtdb/main/install.sh | sh

wtdb init      # writes a starter .wtdb.json
wtdb install   # installs the post-checkout hook
wtdb sync      # provision the current worktree by hand

De config is klein. Het is een .wtdb.json-bestand in de root van je repo.

{
  "envFile": ".dev.vars",
  "dbEnvVar": "DATABASE_URL",
  "pathsToCopy": ["node_modules", ".next"]
}

pathsToCopy is alles wat je worktree nodig heeft om te draaien en wat in gitignore staat. .next gaat hier uit van Next.js, vervang het door je eigen buildcache.

Er is ook wtdb status om te zien welke worktree welke database bezit en wtdb prune om de wezen op te ruimen nadat je een worktree hebt verwijderd. Ik zou graag zien dat git een soort worktree-hooks toevoegt, zodat ik wtdb prune helemaal niet nodig heb.

Voorlopig is er alleen een Postgres-adapter, want dat gebruik ik. De databaselaag is een gewone interface (Copy en Drop), dus als je iets anders gebruikt, is een adapter toevoegen een kwestie van minuten. PR’s welkom.

Github: willhackett/wtdb.