Why Your Worktree Directory Becomes Unmanageable Past Ten Active Tasks

Run git worktree list in your repo. If you see more than ten entries and you cannot explain what each one is for, your worktree setup has graduated from helpful to hazardous.

What unmanageable looks like

The first three worktrees are easy. You remember which task each one is for. The fifth worktree is when you start using ls to remember. The tenth is when you start deleting worktrees you do not recognize, and one of them turns out to have uncommitted work.

The pattern is consistent. Worktrees accumulate. They do not self-clean. Each one holds a branch, a set of untracked files, sometimes a running agent. Without an explicit lifecycle, they live forever.

The three rules I use

Rule one: worktrees live outside the repo, not inside. A subfolder inside the repo gets indexed by your editor, scanned by your test runner, and picked up by globs. A sibling directory at ../<repo>-worktrees dodges all of that.

Rule two: every worktree is named after its task. Not after the date, not after the agent, not after the file. The task ID is the only stable identifier across the lifecycle.

Rule three: cleanup is a separate command, and it never runs by default. Listing and removing are different operations. Dirty worktrees survive one removal attempt and require a second explicit one.

Why each rule exists

Sibling directory exists because of editor indexing. I have had typecheck break in the main repo because an inner worktree held a stale .ts file. The fix is structural, not behavioral.

Task-based naming exists because date-based names stop being meaningful two days later. A date tells me nothing. A task ID like dev-23-epic-add-nestjs-api tells me everything.

Two-step cleanup exists because I have lost work to a single typo. The default is safe. The explicit opt-in is the dangerous path. That is the right default for any operation that deletes files.

What worktree organization does not solve

Organized worktrees do not mean organized work. You can have ten clean worktrees and ten branches that conflict at merge time. Organization is a property of the filesystem. Coordination is a property of the plan.

You will still hit merge conflicts. You will still hit logical dependencies between branches. Worktree organization makes the cleanup survivable. It does not make the plan correct.

List yours

Run git worktree list. For each entry, write the task it corresponds to in one sentence. If any row is blank, that worktree is either finished and should be removed, or forgotten and should be investigated.