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:
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.
Yeah, the untracked files not being copied is also a big reason why I’ll typically just switch to a different branch instead.
I mainly use worktrees when it’s useful that untracked files are not copied, like when I need to check out a completely different state of the project, where cached files would need to be invalidated anyways, for example.
yeah, I think these are the main hurdles for me:
Mainly .env files, as they are handcrafted. And:
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.
Yeah, the untracked files not being copied is also a big reason why I’ll typically just switch to a different branch instead.
I mainly use worktrees when it’s useful that untracked files are not copied, like when I need to check out a completely different state of the project, where cached files would need to be invalidated anyways, for example.