Using git‑worktree to Manage Multiple Branches and Hotfixes Efficiently

Developers often need to switch from a long‑running feature branch to an urgent hotfix, and the usual solutions—committing unfinished work or using git stash —can be cumbersome in many situations such as long tests, large projects, differing environments, or debugging a colleague's code.

Cloning multiple repositories to solve these problems introduces its own issues: difficulty synchronising state, duplicated history that inflates disk usage, and management overhead.

Git’s git‑worktree feature, available since 2015, allows a single repository to have several independent worktrees, each checked out to a different branch without interfering with one another.

Running git worktree --help shows the four primary commands:

git worktree add [-f] [--detach] [--checkout] [--lock] [-b
]
[
]
git worktree list [--porcelain]
git worktree remove [-f]
git worktree prune [-n] [-v] [--expire
]

Two Git fundamentals are important: a newly initialised repo has only one worktree called the main worktree , and any directory used with Git must contain either a .git folder or a .git file that points to the actual worktree directory.

Example: after creating a worktree with git worktree add ../feature/feature2 , the project structure expands from a single root to include a feature/feature2 directory, and the new worktree contains a .git file whose content points to /path/to/repo/.git/worktrees/feature2 .

When branch names contain slashes (e.g., feature/JIRA123‑Title ), Git would treat the slash as a directory separator; using the -b option (e.g., git worktree add -b "hotfix/JIRA234-fix-naming" ../hotfix/JIRA234-fix-naming ) creates the branch correctly.

Listing all worktrees with git worktree list shows each path, the current commit hash, and the branch name, including the main worktree.

To delete a worktree, use git worktree remove ; if the worktree has uncommitted changes, add the -f flag. After removal, running git worktree prune cleans up any leftover administrative files.

In summary, the complete workflow consists of the four commands git worktree add , git worktree list , git worktree remove , and git worktree prune , providing a cleaner alternative to cloning multiple repositories.

Practical advice includes organizing worktrees under dedicated feature and hotfix directories and avoiding tracking worktree contents via .gitignore .

Typical questions: Can the main worktree be deleted? How does the .git/worktrees directory evolve with repeated creation and deletion?