using-git-worktreeslisted

# Using Git Worktrees Isolate work so it can't collide with your main checkout or another agent's. A worktree is a second working directory on its own branch, sharing one repository — the cheap way to get isolation without a second clone. ## When to use - A plan of several tasks, a risky refactor, or parallel agents that must not share a working tree. - **Skip** when isolation already exists (you're already on a dedicated branch/worktree), or for a quick one-liner you'll commit on the current branch. ## Procedure 1. **Prefer existing isolation.** If your harness already gives each task an isolated workspace, use that — don't stack a git worktree inside it. Fall back to `git worktree` only for a plain shared checkout. 2. **Create it outside any scanned tree.** A sibling dir (`git worktree add ../{{repo}}-{{branch}} -b {{branch}}`), or a `.worktrees/{{branch}}` subdir that is gitignored. Never create one inside a path a docs generator or build scans. 3. **Confirm the .gitignore covers it.** If the worktree lives under the repo, that path MUST be gitignored — otherwise the worktree's own files get committed into the parent. 4. **Isolate the runtime, not just the code.** A worktree shares nothing automatically: a dev server, database, or migration from one worktree collides with another's if they share a port/DB/state. Give this worktree its own port, database name, and env — declare them up front, don't discover the clash mid-run. 5. **Install dependencies fresh.** A new wo