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

Programming

21948 readers
739 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
115
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups (www.tomups.com)
submitted 3 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 3 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.

[โ€“] troglodyke@lemmy.federate.cc 2 points 2 days ago

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)

load more comments (5 replies)