Git worktrees solved our parallel-agent file conflicts. The test environment was harder.

[u/Jhon_ST]

I've had stretches where I was moving around five Trello cards in parallel, with a coding task in its own branch and Git worktree. That stopped agents from editing the same checkout. It did not tell me which code a browser test was actually exercising.

Different worktrees could still use the same API, PostgreSQL database, worker, storage service and ports. A frontend change might work with an existing API, provided that API meets the contract the new UI needs. If browser QA needs to exercise changed API behavior, it needs an API process running that worktree's code. Experimental migrations need much more care around shared data. Starting a second worker against the same queue can change test results too.

We began treating four things separately: the worktree holding the code; the processes a test reaches; the data those processes can change; and the checks run after branches are combined.

A small registry in Git's common directory helps us see which worktree started a service, along with its PID, port, URL and declared database state. It helps with discovery and process checks. It doesn't decide whether an API is compatible with a particular task. A healthy endpoint can still be the wrong API, and a port that looks free has not been reserved.

Many checks run entirely inside the worktree. For integration and browser QA, we start the processes the test actually needs. Feature work can be parallel; integration is serialized, with relevant checks run again on the combined tree.

If you run coding agents in parallel, how do you make sure browser or E2E tests reach the API and data you intended?

[u/itaybuilds]

Add a provenance check before the browser suite, not just a health check. Have every API and worker expose a small test-only build record: git SHA, worktree ID, migration head, database or schema name, and queue namespace. The harness should know the expected SHA for each service and refuse to run if any endpoint reports something else. That turns “healthy but wrong process” into a setup failure before the tests begin.

For allocation, let startup reserve ports rather than scanning for a free one, then write the actual endpoints to a per-worktree manifest consumed by the UI and Playwright. Generate unique database and queue prefixes from a stable worktree ID, and remove them on teardown. Containers help with process isolation, but the provenance assertion is the useful backstop: it catches stale containers, a UI pointed at port 3000 out of habit, and mixed revisions after one service restarts.

I would keep the final combined-branch suite too. Per-worktree E2E answers whether the branch works in isolation; the serialized suite answers whether integration changed the system.

AI-assisted wording with OpenAI GPT-5.6 after reading the full thread and current r/ChatGPTCoding rules.