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.
I’ve stopped using bare env files on the repo, I’ll create an env file that populates values from a secrets manager and check this file info git. Or throw the env file info a parent dir because they’re probably user specific anyway.
Having an env file that needs to exist but isn’t checked into source control creates “works on my machine” issues as well, just load them from the environment and provide a programmatic way of setting the environment (or stop pretending they’re part of the project and use direnv/Mise to setup the env)
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.
So I can’t help with the IDE issue, but my answer to files that need to be available ln every worktree would be symlinks. So your .env in your repo would really be a symlink to the real .env that lives somewhere else in your system. Sure, you need to create a new symlink when creating a new worktree, but otherwise editing the symlinked file updates every worktree.
And of course, for those worktrees that do need their own versions of some files (e.g. maybe you keep an old release branch of the project in a worktree) you’d use a real file and not a symlink
If they’re ignored files, setting them up locally won’t end up in the repo. If you put a symlink into the repo, fixing that for your setup will register as a change within git, which can cause annoyance and even problems down the line.
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.
I’ve stopped using bare env files on the repo, I’ll create an env file that populates values from a secrets manager and check this file info git. Or throw the env file info a parent dir because they’re probably user specific anyway.
Having an env file that needs to exist but isn’t checked into source control creates “works on my machine” issues as well, just load them from the environment and provide a programmatic way of setting the environment (or stop pretending they’re part of the project and use direnv/Mise to setup the env)
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.
So I can’t help with the IDE issue, but my answer to files that need to be available ln every worktree would be symlinks. So your
.envin your repo would really be a symlink to the real.envthat lives somewhere else in your system. Sure, you need to create a new symlink when creating a new worktree, but otherwise editing the symlinked file updates every worktree.And of course, for those worktrees that do need their own versions of some files (e.g. maybe you keep an old release branch of the project in a worktree) you’d use a real file and not a symlink
Then we have the “it works on my machine” issue. I’m vehemently against symlinks pointing out of the code repository because of that.
If they’re untracked files anyway, that’s unavoidable.
If they’re ignored files, setting them up locally won’t end up in the repo. If you put a symlink into the repo, fixing that for your setup will register as a change within git, which can cause annoyance and even problems down the line.