Git branch already checked out: find the owning worktree before forcing it

By ON Lab · Sources checked November 8, 2026

When Git says a branch is already checked out at another location, first inspect the registered worktrees and the branch at that path. Using the existing checkout or deliberately moving it to another branch can resolve normal occupancy. Deleting .git/worktrees is not a safe substitute for understanding the relationship: that directory holds bookkeeping for linked checkouts.

A historical reader asked how to handle the occupied-branch error without deleting that metadata. We checked current Git worktree and switch documentation. This is an official-source guide, not a recreated linked-worktree test. We did not create, remove, repair or force any linked worktree in this run, and did not inspect the reader's repository.

Locate the checkout that currently holds the branch

git worktree list --porcelain

The structured output records worktree paths and details such as HEAD and branch association. Match the full branch reference and path, rather than guessing from directory names. A folder named after a branch may currently hold a different branch, and a branch can have changed since that folder was named.

git -C "/path/from-the-list" status --short
git -C "/path/from-the-list" branch --show-current

Replace the path with the actual listed checkout. Inspect its current state before changing anything. Uncommitted modifications and untracked files belong to that working directory and do not become safely stored merely because a branch points to its committed HEAD.

If another person or process is actively using that checkout, coordinate its ownership before switching it. An occupancy error can be a useful signal that the branch already has an active working location.

Choose the smallest appropriate normal-case action

What you need	Normal direction	Check first
Continue work on that same branch	Use the checkout already holding it	Its path, branch and local changes
Use the branch in a different existing checkout	Deliberately free it in the current owning checkout first	Whether that owner's work is preserved and the alternate branch is intended
Inspect the same committed state independently	Review a detached or separate-branch workflow	Whether you need a branch pointer that will move with new commits

These are different goals. A detached view can inspect a commit without being a second checkout of the same branch pointer, but committing while detached needs an explicit preservation plan. The detached-HEAD guide explains that distinction.

This guide does not require another worktree just to silence the error. If the existing checkout is the intended place to work, using that location can be the complete normal-case answer.

Free a branch only after reviewing the owning checkout

If the project intentionally wants to move branch usage elsewhere, inspect and preserve the old checkout's work, then select an appropriate different branch or another reviewed state there. Re-run worktree list afterward and verify that the branch is no longer associated with that checkout before trying the desired operation in the other location.

A branch switch is not a backup procedure. Do not assume that it stores uncommitted changes or that a force option will choose the right contents. The choice of preservation method depends on the files and the team's workflow, so review the actual status rather than applying an unrelated cleanup recipe.

Why forcing or deleting metadata changes the question

The current worktree manual documents guards against checking out a branch already held elsewhere. Force-related options can override safeguards; their availability does not establish that two independently edited checkouts should share one moving branch pointer.

Manually removing the bookkeeping can leave a directory of files whose relationship to the main repository is no longer correctly recorded. It can also obscure where uncommitted work lived. Read the registered state and use the documented worktree operations for the situation instead of deleting internal files to make the message disappear.

If the path moved, disappeared or is temporarily offline

A normal occupied branch and damaged or stale location information are separate cases. The worktree manual documents repair for reestablishing connections after manually moving repositories or linked worktrees. That operation is not a general remedy for every ordinary occupancy message.

It also documents pruning stale administrative entries, including a dry-run mode. Before treating a missing path as stale, verify whether its drive, network mount or removable storage is simply unavailable. A locked worktree may intentionally retain its bookkeeping while offline. A missing directory in one moment is not proof that its work was intentionally deleted.

Inspect the corresponding documented repair or prune procedure only after establishing which state actually occurred. We did not test those recovery operations and do not claim that metadata cleanup would recover the reader's files.

Verify the relationship after the chosen action

Read the full worktree list and identify the actual branch/path pair.
Inspect the owning directory's branch and uncommitted state.
Choose whether to use that location, free the branch deliberately or use another reviewed history view.
Re-read the worktree list and the relevant directory status.
Confirm that intended committed and uncommitted work remains available before proceeding.

If two locations appear to hold the same branch unexpectedly, retain that evidence and investigate the specific metadata or tool behavior. Do not generalize the ordinary one-owner guidance into a diagnosis of a corrupted repository or an IDE bug.

Checked November 8, 2026 against current Git manuals and the historical occupied-branch question. No linked worktree operations, original repository metadata, IDE behavior, forced checkout, repair or pruning were executed.