using-git-worktreeslisted

# Using Git Worktrees A worktree is a separate working directory tied to the same repo. It lets you have multiple branches checked out simultaneously, each in its own folder. Your main checkout stays clean. Always. ## Iron Law **Never `git checkout -b feature/x` in your main working directory.** Spawn a worktree. Main stays on `main`, no exceptions. ## Why worktrees beat branch-switching | Pain with `checkout` | How worktrees solve it | |---|---| | Stash dance when interrupted | Other worktree exists; just `cd` to it | | Half-applied changes leak between features | Filesystem isolation, impossible to mix | | `node_modules` / build artifacts thrash | Each worktree has its own build state | | Hard to compare current vs. proposed | Open both in two editors side-by-side | | Discarding a branch is scary | Just `rm` the worktree dir, branch optional | ## Red Flags - Working on a new feature in the same directory you used yesterday. - A `git stash list` longer than two entries. - "Let me switch branches" mid-task — that's the moment to spin a worktree instead. - Uncommitted changes hanging around because switching loses them. ## Standard Flow ### 1. Start ```powershell # from repo root git fetch origin git worktree add ../repo-feature-x -b feature/x origin/main cd ../repo-feature-x ``` Now you're on a fresh `feature/x` branch in an isolated directory, branched from latest `origin/main`. If your harness has an `EnterWorktree` tool, use it — it manages the lifecycle for yo