Worktrees are great. Although I use them is a different way. I only use them to allow me to rebase or cherry pick onto branches, which require a working tree to do, without ever leaving my main branch. Basically I use them as more powerful branches then full worktrees.

Instead I just do all my work in the main branch/worktrees. When I have something I want to push to a pr I commit just that change to main. Then create a branch and work tree (I store them in .git/wt/). Then cherry pick the commits onto that branch and push that creating a pr from it. Then go back to working on main again on top of the changes I have done. Once the pr gets merged I do a pull --rebase which drops the commits from main.

This means I don't need to switch directories ever and let's me work on a feature, then do a refactor (or minor bug fix), commit and push the refactor in isolation while continuing to work on the feature on top of the refactor.

Glad it's there for people who need it. I've been fine with branching and stashing for 10+ years and my working directories have never been so dirty that I needed an entirely new copy of the project to do a hotfix.

I never really understood the advantage of worktree over having just several clone of the repos on different folders.

Can someone explain me ? I should have missed smth.

VSCode just added support too fyi

Oh my god, I've thinking about why git doesn't operate this way for ages, but it already has for a decade. This is going to change my life. Thank you for posting this.

Functionality-wise, it seems very similar to just "git cloning" another copy of the repo in a different directory (you can even use the "main" local repo as its source, and "pull" from that), which at least to me seems more intuitive to reason about and doesn't require me to learn any new commands or worry about any limitations like the issues with submodules or not being able to have the same branch checked out twice (clones don't mind).

It's a nice idea, and I'm going to try to remember them as an option for future scenarios where they might be useful, but I think the reason they never caught on generally is just that they're not bringing anything to the table that can't already be easily accomplished by other means.

yeah, I think these are the main hurdles for me:

1. Untracked files are not copied

When you create a new worktree, it is created from whatever is comitted, so gitignored or uncomitted files are not copied.

So if you have .env files, you have to copy them over manually. And for dependencies, like for example node_modules, you would have to run npm install again in the new worktree.

Mainly .env files, as they are handcrafted. And:

2. Editor / IDE complexity.

A few projects I work on are multi-root (using VS Code terminology) and that's already complex enough. Adding worktree directories means adding a level to that, which I'm not bought in. And I don't want a separate workspace for each branch I work on, that just shifts the complexity from git to the IDE / editor.

I use them all the time, but that's just because of Yocto and the need to keep at least the 3 major LTS builds hot in the event something breaks.

This is pretty cool and solves one of the problems I've had whilst playing around with things like Cursor: that it breaks my flow having to wait 5-10 minutes for it to generate code/documentation, I'd really like to use that time to focus on my main work whilst it does some grunt work. Worktrees looks like it might provide a solution to this

Worktrees are great, unless you have submodules...

Unfortunately some developer tools fail to work correctly in separate worktrees. I used them for a while but had to give them up. For example, Maven's release plugin cannot reliably create tags / branches if you're in a separate worktree.

Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don't work with submodules.