worktree-ops

Worktree Management

Git worktrees let you check out multiple branches of the same repository into separate directories simultaneously. Each worktree has its own working directory and index while sharing the same .git object store and history. This is useful for running parallel development sessions, reviewing a PR while mid-feature, or isolating experimental changes without stashing or committing half-finished work.

Core Principles

Principle	Meaning
Isolation without duplication	Worktrees share git history but keep working directories separate - no need to clone the repo again
Safety first	Always check for uncommitted changes and unpushed commits before removing a worktree
Clean up after yourself	Stale worktree entries and orphaned branches accumulate - prune regularly
Convention over configuration	Use a consistent directory layout (.worktrees/<name>/) and branch naming (worktree-<name>)

Quick Reference

Command	What it does	When to use
git worktree add <path> -b <branch>	Create a new worktree with a new branch	Starting parallel work on a new task
git worktree list	Show all worktrees with their branches and paths	Checking what is active
git worktree list --porcelain	Machine-readable worktree listing	Scripting or enriching with status info
git worktree remove <path>	Remove a worktree directory and its admin files	Done with a parallel task
git worktree remove <path> --force	Force-remove even with uncommitted changes	After explicit user confirmation
git worktree prune	Clean up stale worktree entries	After manual directory deletion or errors
git branch -D worktree-<name>	Delete the orphaned branch after worktree removal	Keeping branches clean

Create

Create a new worktree for an isolated parallel development session.

Workflow

1. Confirm the current directory is a git repository.
2. Confirm the current session is NOT already inside a worktree:

   git rev-parse --is-inside-work-tree && git worktree list
   

   If the current working directory is already a worktree (not the main working tree), warn the user and stop.
3. If a name was provided as an argument, use it. Otherwise, present an interactive prompt (or the platform's equivalent): "What name should I use for this worktree? (e.g., feature-auth, bugfix-123)"
4. Create the worktree:

   git worktree add .worktrees/<name> -b worktree-<name>
   

5. Change your working directory to the new worktree path.
6. Report to the user:

   Worktree created:
     Directory: .worktrees/<name>/
     Branch: worktree-<name>
     Based on: <current HEAD>
   

7. Remind the user:
   • Run your stack's dependency installation command (e.g., composer install, npm install, pip install -r requirements.txt)
   • The worktree shares git history with the main repo but has its own working directory
   • Use the list command to see all active worktrees
   • Use the remove command to clean up when done