Your Setup Script Should Support Git Worktrees

On one production app I work on, a fresh Git worktree becomes runnable with one setup script:

bin/setup

Setup prepares the environment and exits, then the normal development command runs. I’ll use bin/dev here as shorthand for whatever command the repository already uses. Setup doesn’t hide the server inside a clever process manager.

bin/setup is a repo-owned executable that turns a checkout into a working development environment. Call it make setup or script/bootstrap if that fits your project. The interface matters more than the name: one command returns either a ready repository or exact repair instructions.

The same command should work from every Git worktree. Parallel coding agents made this important enough to treat as ordinary development infrastructure.

A Second Checkout Is Not a Second Environment

A Git worktree is another checkout with its own working tree, HEAD, and index while sharing the repository’s common Git data. That separation is great for code. Git does not know that both copies of the app want the same port, database, cache keys, callback URL, Terraform state, or container name.

This works until two worktrees need to run:

git worktree add ../app-payment-fix -b payment-fix<br>cd ../app-payment-fix<br>bin/setup<br>bin/dev

A setup script written for one permanent clone can copy the same .env and point every checkout at the same databases. When two worktrees start, their dev servers can fight for host ports. Compose projects can also overlap when they reuse a project name or fixed container, network, or volume names, and published ports still collide. The second worktree either fails to start or quietly shares state.

Worktrees existed long before coding agents. What changed is frequency. Keeping two branches open used to be an occasional convenience. Now several agents can implement and test unrelated changes at once. Their files are isolated by Git; their runtime state has to be isolated by the repository.

Share Services, Isolate Names

Running a complete Docker stack for every worktree is the simplest mental model and often the wrong default. Databases, object storage emulators, mail catchers, and other local services can be expensive compared with an app process. I run one shared stack, then give each worktree its own ports, databases, and resource names.

Shared once per machine<br>Isolated per worktree

Database and cache servers<br>Development and test database names, cache namespace

Local service containers<br>Queue names, buckets, callback URLs, infra resource names

Package-download and tool caches<br>App port, environment file, logs, PIDs, local state

The setup script derives a readable worktree identity, checks it against a small local registry, then writes generated configuration such as:

WORKTREE_ID=<br>APP_PORT=<br>DATABASE_NAME=app_dev_<br>TEST_DATABASE_NAME=app_test_<br>Registry allocation needs a lock because agents can start setup together. The lock only serializes setup processes that honor it. A robust allocator should remove stale reservations, pick a candidate port, check for a current listener, then commit the identity atomically.

That listener check is only a snapshot. The dev command must still report a later bind collision clearly. A script can be safe to rerun and still fail under concurrency; idempotence alone is not enough.

What bin/setup Owns

Setup owns every step between git worktree add and the normal development command:

Bootstrap the repository&rsquo;s declared toolchain (I use mise).

Run bin/doctor to diagnose remaining host requirements, stopping with exact repair steps if needed.

Ensure the shared Docker services are running and healthy.

Allocate or recover the worktree&rsquo;s identity and ports.

Generate local environment and service configuration.

Create and migrate isolated development and test databases.

Verify the app can reach its dependencies, then exit.

That bootstrap does not have to be mise. I use mise to pin language runtimes, package managers, and small CLI tools in the repository. Setup can run mise install for missing configured versions. Git, Docker, operating-system libraries, and credentials may still be required.

If a repository uses mise, installing a tool does not activate it for every shell. Setup should run repo commands through mise exec -- ... or explicitly require shell activation, so incidental shell configuration cannot change the result.

This shortens time to first commit, but onboarding is only the first payoff. The same path runs whenever a human or agent opens a worktree.

Make Setup Fail Early

bin/doctor belongs near the start of setup and should also run independently. Before I added it, setup could reach the seed step before discovering ffmpeg was missing. Doctor now catches that before the expensive work begins.

A useful doctor checks every requirement, collects all failures, exits nonzero, and prints repairs a person can paste:

FAIL container engine:...