worktree

Git Worktree

Use one reusable branch and worktree per logical change. Follow repository and user rules. Run later commands and edits in the selected worktree. Respond in the user's language.

Do not silently stash, move uncommitted work, overwrite directories, or force-delete branches or worktrees.

Inspect and reuse

git rev-parse --show-toplevel
git status --short --branch
git worktree list --porcelain
git branch --list

Read relevant repository instructions. Determine whether the current worktree fits the task, the target branch is checked out elsewhere, an existing branch/directory can be reused, uncommitted work is required, or governance documents must precede coding.

If uncommitted changes must move, ask the user to choose committing, making a patch, or staying in the current worktree. Do not transport them silently.

Conditional governance baseline

Only when repository or user rules require governance documents to enter the mainline before coding:

1. Identify the actual mainline; do not assume main.
2. Use its existing clean checkout and synchronize according to repository rules without overwriting other work.
3. Change only required governance documents, run documentation gates, and commit them separately on the mainline.
4. Record the immutable commit SHA as the coding baseline.
5. Bring an empty coding worktree to that baseline. If it already contains code, integrate by the repository's merge rules without rewriting history.

If permissions or dirty state prevent this safely, report the obstacle before coding.

Select branch, base, and directory

Prefer user-specified names and repository conventions; otherwise use a short task slug with feat/, fix/, docs/, chore/, or work/ as appropriate.

Choose the base in this order: required governance commit, explicit user choice, repository rule, related branch, then current HEAD. Clarify a choice that materially changes the work. Fetch only when requested for freshness or required by repository rules; disclose an offline baseline.