Git worktrees - Lesson 4 of 5

Clean up through Git, recover through Git

A worktree has filesystem state and Git metadata. Let Git remove and move it when possible; when a path has already changed, diagnose whether you need prune, repair, or a lock.

Time: 12 minutesPrevious: integrateReference: field guide

The normal closeout

cd ../repo-readme-refresh
git status --short
git log --oneline main..HEAD

cd ../repo
git worktree remove ../repo-readme-refresh
git branch -d docs/readme-refresh
git worktree list --verbose

Removal should be boring: no uncommitted work and no unintegrated commits you intend to keep. Git refuses to remove an unclean worktree by default. Treat that refusal as evidence to inspect, not as an invitation to add --force.

Match the problem to the repair

SituationFirst commandPurpose
Path was moved intentionallygit worktree move <old> <new>Move directory and metadata together.
Path was moved by handgit worktree repair <new-path>Reconnect Git metadata to its actual location.
Path was deleted by handgit worktree prune --dry-runPreview stale metadata removal.
Path lives on removable storagegit worktree lock --reason "external disk" <path>Prevent automatic pruning while unavailable.
Per-worktree tool settings are neededgit config --worktree ...Use after enabling worktree-specific configuration.

Recovery sequence

Stopdo not force yetListread verbose stateLocatepath moved or missingRepairreconnect a moved treePreviewdry-run stale cleanupPruneonly after review
git worktree list --verbose
git worktree repair ../repo-moved
git worktree prune --dry-run
git worktree prune

repair reconnects a worktree that still exists at a new path. prune removes stale records for a path that is missing. Those are different problems.

Retrieval check

Primary reading

Ask follow-up questions: If a worktree has disappeared or reports as prunable, share the output of git worktree list --verbose before doing cleanup.