I use git worktrees daily. I'm surprised by how hard it can be to explain them to people who have never used them. Lately I've settled on "like clones, but sharing a .git directory." The article tries to get this across by comparing them to branches, but I think clones are a more intuitive concept to compare against.

To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/

Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.

Fossil SCM, conventionally, has been thus way by default.

https://fossil-scm.org/home/doc/trunk/www/gitusers.md

The one real caveat to this is that if your application has particularly heavy cold starts it can be hard to actually run your worktrees. I usually end up swapping to a regular checkout as each worktree is due for hands-on attention.

wt is a useful little tool for helping with git worktrees: https://github.com/timvw/wt

I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.

This is very interesting and could be very helpful for A/B testing or comparing outputs/speed between 2 branches.

I already know a place I want to use this.

I do the same thing just checking out the repo multiple times in different directories.

I'm not really sure what worktrees adds on top of that.

What a peculiar title. The title suggest parallel dev without using worktrees, but the article is about using worktrees.