Jeder Worktree bekommt seine eigene Datenbank

Ich arbeite inzwischen fast nur noch in Git-Worktrees. Agentisches Coding und echte Feature-Entwicklung laufen bei mir jeweils in einem Worktree, damit alles, was ich gerade mache, von anderen Arbeitsströmen isoliert ist. Das gefällt mir, weil ich an etwas arbeiten, es liegen lassen und etwas anderes anfangen kann, ohne nebenan auf dem herumzutrampeln, was ich dort offen habe.

Wer hätte gedacht, dass Worktrees (ein Feature, das ich seit einem Jahrzehnt in git help ignoriert habe) zur Killer-Technologie von 2026 werden.

Wenn du Worktrees nicht kennst, kannst du hier nachlesen.

Es gibt ein Problem. Worktrees klonen deinen Code. Sie klonen nichts, was nicht in Git eingecheckt ist, und davon brauchst du zwei Dinge: deine gitignorierten Dateien und eine Datenbank. Also verbindet sich jeder Worktree, den du anlegst, fröhlich mit demselben lokalen Postgres. Sobald ein Branch eine Migration ausführt, hat er das Schema geändert, auf das die anderen drei angewiesen sind, und weg ist meine perfekte Isolation.

Also habe ich ein kleines Tool geschrieben, um das zu beheben: wtdb.

Mein Setup sieht so aus:

main-repo/: folgt immer origin/main, Migrationen laufen nach jedem Pull. Die saubere Referenzkopie.
main-repo-worktree-feat-blah-blah/: ein Worktree für einen Feature-Branch mit eigener Datenbank, dazu Cache und node_modules, aus dem Haupt-Repo kopiert.
main-repo-worktree-feat-foo-bar/: ein weiterer Worktree für einen Feature-Branch mit eigener Datenbank, dazu Cache und node_modules, aus dem Haupt-Repo kopiert.

Wenn ich einen Worktree hinzufüge, hängt sich wtdb in den post-checkout von Git und erledigt die drei langweiligen Dinge, die niemand von Hand einrichtet:

Klont die Datenbank. Es nutzt das CREATE DATABASE ... TEMPLATE von Postgres. Das ist also eine fast sofortige Kopie deiner Dev-Daten und kein Dump-and-Restore, bei dem du dir einen Kaffee holen gehst.
Kopiert deine Env-Datei und schreibt die Datenbank-URL so um, dass sie auf die neue Kopie zeigt.
Kopiert die gitignorierten Teile, die du wirklich brauchst. Das sind node_modules und Co. per Copy-on-Write-Klon, das kostet dich also keinen Speicherplatz.

Jetzt kann ich einen Dev-Server gegen jeden Worktree laufen lassen und einen Agenten in seiner eigenen Sandbox alle Migrationen und Schemaänderungen ausführen lassen, auf die er Lust hat.

Der Einstieg ist eine Installation und drei Befehle:

# Prüf immer den Quellcode eines neuen Tools, bevor du es installierst.
# Ich weiß, dass das keine gute Praxis ist. Ich stelle es bald über Homebrew bereit. Vielleicht.
curl -fsSL https://raw.githubusercontent.com/willhackett/wtdb/main/install.sh | sh

wtdb init      # schreibt eine .wtdb.json als Startpunkt
wtdb install   # installiert den post-checkout-Hook
wtdb sync      # richtet den aktuellen Worktree von Hand ein

Die Konfiguration ist klein. Es ist eine .wtdb.json-Datei im Root deines Repos.

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

pathsToCopy ist alles Gitignorierte, was dein Worktree zum Laufen braucht. .next setzt hier Next.js voraus, tausch es gegen deinen eigenen Build-Cache.

Es gibt außerdem wtdb status, um zu sehen, welcher Worktree welche Datenbank besitzt, und wtdb prune, um die Waisen zu löschen, nachdem du einen Worktree entfernt hast. Ich hätte gern, dass Git irgendeine Art von Worktree-Hooks bekommt, damit ich wtdb prune gar nicht brauche.

Aktuell gibt es nur einen Postgres-Adapter, weil ich Postgres nutze. Die Datenbankschicht ist ein schlichtes Interface (Copy und Drop). Wenn du etwas anderes nutzt, ist ein Adapter in ein paar Minuten gebaut. PRs willkommen.

Github: willhackett/wtdb.