> maintenance & cleanup
Every worktree leaves two footprints: the directory on disk and metadata inside the repository (.git/worktrees/<id>). These commands manage both — remove deletes a worktree properly, prune clears metadata for directories that vanished without it, move and repair keep the cross-links valid when paths change, and lock protects worktrees on removable media from being pruned as "gone". Most "git thinks a branch is checked out but it isn't" mysteries end here.
// maintenance & cleanup
6 commands$ git worktree remove ../myapp-hotfix$ git worktree prune --dry-run -v$ git worktree move ../myapp-hotfix ~/work/hotfix$ git worktree repair$ git worktree lock --reason "on portable SSD" ../myapp-usb$ git worktree remove ../myapp-agents/auth// faq
I deleted a worktree folder with rm -rf — why does Git still complain?
Because the repository-side metadata in .git/worktrees survived, Git still believes the worktree exists and its branch is checked out. Run git worktree prune to drop the stale entries; the "already checked out" and "cannot delete branch" errors disappear with them. Git would auto-prune eventually (gc.worktreePruneExpire, default 3 months), but there's no reason to wait.
Does removing a worktree delete the branch or its commits?
No. remove only deletes the working directory and its metadata; the branch and every commit stay in the repository, ready to be checked out again. The one thing to fear: commits made on a detached HEAD in that worktree belong to no branch and become garbage-collectable — create a branch for them before tearing down.
Why does git worktree remove keep refusing?
It refuses unclean trees — and "unclean" includes untracked files, so a single build artifact or a node_modules directory is enough. Check git -C <path> status, then use --force when the leftovers are disposable. Locked worktrees demand --force twice, on purpose.
I moved my main repo and every worktree broke. Now what?
Worktree links are absolute paths by default, so relocating the main repository orphans them ("fatal: not a git repository"). Run git worktree repair from the main worktree to fix the links; for worktrees you moved manually, run repair inside them or pass their new paths as arguments. If your repos relocate often, recent Git offers worktree.useRelativePaths=true so the links survive moves.