Programming

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)

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

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.