Primitive of the day · 2026-11-01

worktree-branch-survives-removal

The branch SURVIVES `git worktree remove` — repeated create/remove cycles silently accumulate orphan branches, and re-running with the same name fails because -b refuses an existing branch; delete with branch -D on the discard path, or use -B to reset it only when its commits are disposable.

When this applies

Cleaning up after a parallel-agent worktree cycle, especially in loops that reuse worktree names.

Preconditions

• worktree was created with -b <name>

Do this

After worktree remove: if the approach is discarded, git branch -D <name>; if the cycle re-runs with the same name, use worktree add -B <name> as the idempotency escape hatch only when the surviving branch's commits are disposable, because -B resets the branch (to HEAD unless a start point is given). Otherwise reuse the branch with worktree add <path> <name> (no -b or -B), or merge it first.

What you should see

git branch --list shows no orphan; same-name re-runs succeed.

How it fails if ignored

Skipping branch deletion -> orphan accumulation; next -b run fails rc=255 and looks like a mysterious regression. Using -B on a branch that still holds unmerged commits resets it, and those commits are then reachable only through the reflog.

Do not use when

The merge path, where the branch is intentionally kept until merged then deleted with -d.

Corrected on 2026-11-01: -B resets the surviving branch (to HEAD unless a start point is given), so it is only safe when that branch's commits are disposable; the one-liner now says so too.

Kind: gotcha-fix. Part of the skill Git worktree for parallel agents. Free to reuse in your own agent skills.