Git worktree guide for working on multiple branches at once draws Hacker News attention

A built-in Git feature gets renewed attention

A tutorial published on barrd.dev explaining Git's worktree feature reached the Hacker News front page, introducing the tool to developers who have spent years juggling branches with stash and checkout. The author, a Bristol-based web developer writing under the barrd.dev banner, points out that worktree has shipped with Git since version 2.5 roughly a decade ago, yet he only discovered it recently while wrestling with a difficult project.

The core idea is simple. Instead of one working directory that you repeatedly re-point from branch to branch, git worktree lets you attach additional working directories to the same repository, each checked out to its own branch. Every directory behaves like a normal checkout: you edit files, commit and push as usual. The difference is that all directories share the same .git object database and commit history, so there is one repository underneath but several independent working states.

Branches versus worktrees

According to barrd.dev, the conventional way of handling parallel tasks — stashing half-finished work, checking out another branch, then restoring everything — is fragile and easy to lose track of, particularly when a production bug interrupts a feature in progress. Worktree replaces that shuffle with a directory-per-branch layout.

Two commands cover the common cases. To check out an existing branch into a new sibling directory:

git worktree add ../my-project-feature feature-branch

To create a new branch and its worktree in a single step:

git worktree add -b new-feature ../my-project-new-feature

There is one notable restriction: the same branch cannot be checked out in more than one worktree at a time, so each worktree needs a unique branch. The author frames this as a hidden benefit, since it nudges you toward a tidy correspondence where each task maps to one branch and one directory, which keeps you mentally oriented.

A feature interrupted by a hotfix

The article walks through a realistic scenario. You start with a single directory, shop, sitting on main. You spin up a feature worktree for a checkout flow with git worktree add -b feature/checkout ../shop-checkout. Then a payment bug hits production, and rather than disturbing the feature work, you create a third directory with git worktree add -b hotfix/payment-fail ../shop-payment-hotfix.

At that point three directories coexist: one on main, one for the feature, one for the hotfix. You can fix and test the bug in the hotfix directory, keep iterating on the feature elsewhere, and leave the main directory free for merges and code reviews.

Merging work back is just ordinary Git, the article emphasises. You commit in the feature worktree, move to the main directory, checkout main, merge the feature branch, resolve any conflicts and push. Nothing new to learn — the win is that because every worktree is dedicated to a single branch, it becomes much harder to accidentally commit to the wrong branch or lose your place when something urgent interrupts you.

Listing, removing and pruning

The guide also covers housekeeping. Running git worktree list shows every worktree Git knows about, along with the branch checked out in each, which helps you avoid trying to reuse a branch already attached elsewhere.

To remove a finished worktree, use git worktree remove ../my-project-feature. Git refuses if the worktree has uncommitted changes or untracked files unless you pass --force, and it can never remove the main worktree. One caveat the article stresses: removing a worktree deletes only the working directory, not the branch itself, and you should run git status inside it first to avoid losing uncommitted work.

If you delete a worktree directory manually instead, Git keeps stale metadata and the entry shows up as missing in the list. The fix is git worktree prune, optionally with an expiry such as --expire 7.days.ago to limit cleanup to older entries, or --expire now to clear everything immediately.

Why it matters

Context switching is one of the larger hidden costs in development work, and the stash-and-switch routine amplifies it. Worktree attacks that cost directly: each workstream gets its own directory, stashing becomes a rare exception, and an urgent hotfix no longer derails whatever you were in the middle of. The author's verdict is measured — for simple, sequential work, traditional branching is still fine, and worktree only pays off when you genuinely need to be in two places at once. The article's traction on Hacker News suggests that situation is common enough that plenty of developers are happy to reconsider a feature that has been sitting in Git for about ten years.