Worktree Management¶
List, configure, and maintain your worktrees.
Listing Worktrees¶
View all stackit-managed worktrees:
stackit worktree list
Shows each worktree's anchor branch, path, and status.
Opening an Existing Worktree¶
Switch to a worktree directory:
stackit worktree open my-feature
You can specify either the worktree name or the anchor branch name.
Note
Requires shell integration for automatic directory change. Without it, use:
cd $(stackit worktree open my-feature)
Removing a Worktree¶
Clean up a worktree when you're done:
stackit worktree remove my-feature
This removes:
- The worktree directory
- The worktree registration in stackit
The stack's branches remain intact. Use --force to remove even if there are errors.
Use --keep-branch to preserve the anchor branch when removing the worktree.
Ignored files are deleted with the directory
Deleting the worktree directory deletes everything in it, including files
Git ignores — a .env you edited there, dependency caches, and anything
copied in by a warm start. Git has no copy
of those, so there is nothing to recover them from. Copy out anything you
want to keep before removing.
Attaching to an Existing Stack¶
Attach an existing branch/stack to a new worktree:
stackit worktree attach my-feature
This creates a worktree for an existing stack that wasn't originally created with -w. Useful when you want to work on an existing stack in isolation.
Detaching a Worktree¶
Stop working in a worktree while keeping all of its branches:
stackit worktree detach my-feature
Unlike remove, which refuses when the worktree holds real branches, detach
preserves them: it reparents the stack onto the hidden anchor's parent, deletes
the anchor branch, and unregisters the worktree. Use --force if there are
uncommitted changes.
Detach also deletes the directory
Detach preserves your branches, not the worktree directory — that is
removed, along with every ignored file in it. The same caution as
Removing a Worktree applies: copy out any
warm-started .env or cache you want to keep first.
Pruning Stale Worktrees¶
Clean up worktrees that no longer exist on disk:
stackit worktree prune
Use --dry-run to preview what would be cleaned up without making changes.
Prune skips worktrees that still hold stacked branches or have uncommitted
changes. It does delete directories that are still on disk but empty of stack
branches — and ignored files do not make a worktree count as dirty, so a
worktree holding nothing but a warm-started .env is prunable and that file
goes with it.
Automatic Cleanup¶
During stackit sync, worktrees for merged stacks are automatically cleaned up when worktree.autoClean is enabled (the default).
Configuration Options¶
worktree.basePath¶
Customize where worktrees are created:
stackit config set worktree.basePath "../my-stacks"
Default: ../<repo-name>-stacks
worktree.autoClean¶
Control automatic worktree cleanup during sync:
stackit config set worktree.autoClean false
Default: true
Warm-Starting New Worktrees¶
A new worktree is a fresh checkout, so the ignored files your build needs —
.env, dependency caches — aren't there. Add a .worktreeinclude file at the
repository root to copy selected ignored files into every new managed worktree:
# .worktreeinclude — .gitignore syntax, selects from files Git already ignores
.env
.env.local
node_modules/
The copy runs before post-worktree-create hooks, so setup hooks can use the
warmed files. A pattern can only ever copy a file Git already ignores — never a
tracked file — and an existing file in the destination is never overwritten.
Treat .worktreeinclude as a secrets allowlist
Every managed worktree receives these files. Include secrets only when that
is acceptable for all of them. And because warm-started files are ignored by
Git, nothing else has a copy: remove, prune, and detach all delete
them with the directory.
Post-Create Hooks¶
Run commands automatically after worktree creation by adding a .stackit.yaml file:
# .stackit.yaml
hooks:
post-worktree-create:
- npm install
- cp .env.example .env
Common uses:
- Installing dependencies
- Setting up environment files
- Running initialization scripts
Security
The first time a hook is encountered, stackit prompts for approval. Approvals are stored locally and persist across sessions.
See Configuration for more examples.
Working in Worktrees¶
Run Stack Commands Where the Stack Lives¶
Commands that change branch content — create, modify, absorb, fold,
squash, split, move, reorder, pluck, delete, track — must run in
the worktree that owns the stack, so the edit lands in the working tree you are
actually looking at. From anywhere else stackit refuses and says where to go:
branch payments-api belongs to worktree payments; run this command from there: cd ../myapp-stacks/payments
stackit sync and stackit restack are the exception — they reconcile the whole repository and can run from any worktree.
If the owning worktree's directory no longer exists, cd is not an option; the
refusal points at stackit worktree detach instead, which releases the branches.
Creating Stacked Branches¶
Once inside the worktree that owns the stack, create branches as usual:
# Make changes
git add feature.go
# Create a stacked branch
stackit create add-feature -m "feat: add new feature"
Creating Worktrees from Worktrees¶
You can create new worktrees from inside an existing worktree:
# Inside ../repo-stacks/feature-a/
stackit worktree create feature-b --open
Stackit detects the context and creates the new worktree from the main repository. The new worktree is a sibling, not nested.
Returning to Main Repository¶
# From inside a worktree
cd $(git rev-parse --path-format=absolute --git-common-dir)/..
# Or simply navigate to your original repo path
cd ~/projects/my-repo
Best Practices¶
- One worktree per stack — Keep features isolated for easier context switching
- Clean up after merging — Remove worktrees once PRs are merged, or let stackit sync do it automatically
- Use scopes — Associate worktrees with tickets using
--scopefor better organization - Set up hooks — Configure
post-worktree-createhooks to automate dependency installation