← Tous les articles

Chaque worktree a sa propre base de données

Je fais presque tout mon travail dans des worktrees git, maintenant. Je fais du code agentique comme du vrai développement de fonctionnalités dans un worktree, pour que tout ce que je fais soit isolé des autres chantiers. Ce flux me plaît parce que je peux travailler sur un truc, le laisser et passer à autre chose sans piétiner ce que j’ai ouvert à côté.

Qui aurait cru que les worktrees (une fonctionnalité que j’ignorais dans git help depuis dix ans) deviendraient la technologie phare de 2026.

Si tu ne connais pas les worktrees, tu peux t’y mettre ici.

Il y a un problème. Les worktrees clonent ton code. Ils ne clonent rien de ce qui n’est pas versionné dans git, et il y a deux choses dont tu as besoin : tes fichiers ignorés par git et une base de données. Donc chaque worktree que tu crées se connecte allègrement au même Postgres local. Dès qu’une branche lance une migration, elle change le schéma sur lequel les trois autres comptent, et mon isolation parfaite part en fumée.

J’ai donc écrit un petit outil pour régler ça : wtdb.

Voilà mon organisation :

  • main-repo/ : suit toujours origin/main, avec les migrations lancées après chaque pull. La copie de référence propre.
  • main-repo-worktree-feat-blah-blah/ : un worktree de branche de fonctionnalité avec sa propre base de données, plus le cache et les node_modules copiés depuis le dépôt principal.
  • main-repo-worktree-feat-foo-bar/ : un autre worktree de branche de fonctionnalité avec sa propre base de données, plus le cache et les node_modules copiés depuis le dépôt principal.

Quand j’ajoute un worktree, wtdb s’accroche au post-checkout de git et fait les trois corvées que personne ne met en place à la main :

  1. Il clone la base de données. Il utilise CREATE DATABASE ... TEMPLATE de Postgres, donc c’est une copie quasi instantanée de tes données de dev, pas un dump et restore pendant lequel tu vas te faire un café.
  2. Il copie ton fichier d’environnement et réécrit l’URL de la base pour pointer vers la nouvelle copie.
  3. Il copie les fichiers ignorés dont tu as vraiment besoin. C’est node_modules et compagnie, avec des clones copy-on-write, donc ça ne te coûte pas d’espace disque.

Maintenant, je peux lancer un serveur de dev sur n’importe quel worktree et laisser un agent exécuter les migrations et les changements de schéma qui lui chantent dans son propre bac à sable.

Pour démarrer, il faut une installation et trois commandes :

# 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

La config est minuscule. C’est un fichier .wtdb.json à la racine de ton dépôt.

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

pathsToCopy liste tout ce que ton worktree ignoré par git doit avoir pour tourner. Ici, .next suppose Next.js, remplace-le par ton propre cache de build.

Il y a aussi wtdb status pour voir quel worktree possède quelle base, et wtdb prune pour supprimer les orphelines après avoir effacé un worktree. J’aimerais que git ajoute une forme de hooks de worktree pour que je n’aie plus besoin de wtdb prune.

Pour l’instant, il n’y a qu’un adaptateur Postgres, parce que c’est ce que j’utilise. La couche base de données est une simple interface (Copy et Drop), donc si tu es sur autre chose, ajouter un adaptateur prend quelques minutes. Les PR sont les bienvenues.

Github : willhackett/wtdb.