this post was submitted on 31 Jul 2025
112 points (99.1% liked)

Programming

21924 readers
458 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
UlrikHD@programming.dev
112
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups (www.tomups.com)
submitted 2 days ago by dessalines@lemmy.ml to c/programming@programming.dev
22 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] eager_eagle@lemmy.world 13 points 2 days ago (6 children)

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:

  1. 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.

[–] ugo@feddit.it 6 points 2 days ago* (last edited 2 days ago) (3 children)

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

[–] eager_eagle@lemmy.world 5 points 2 days ago (2 children)

Then we have the "it works on my machine" issue. I'm vehemently against symlinks pointing out of the code repository because of that.

[–] dessalines@lemmy.ml 9 points 2 days ago (1 children)

If they're untracked files anyway, that's unavoidable.

[–] kuberoot@discuss.tchncs.de 3 points 1 day ago

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.

load more comments (2 replies)