this post was submitted on 31 Jul 2025
83 points (98.8% liked)

Programming

21880 readers
316 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
83
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups (www.tomups.com)
submitted 21 hours ago by dessalines@lemmy.ml to c/programming@programming.dev
16 comments fedilink hide all child comments
top 16 comments
sorted by: hot top controversial new old
[–] cecilkorik@lemmy.ca 14 points 19 hours ago (2 children)

Functionality-wise, it seems very similar to just "git cloning" another copy of the repo in a different directory (you can even use the "main" local repo as its source, and "pull" from that), which at least to me seems more intuitive to reason about and doesn't require me to learn any new commands or worry about any limitations like the issues with submodules or not being able to have the same branch checked out twice (clones don't mind).

It's a nice idea, and I'm going to try to remember them as an option for future scenarios where they might be useful, but I think the reason they never caught on generally is just that they're not bringing anything to the table that can't already be easily accomplished by other means.

[–] 6nk06@sh.itjust.works 1 points 4 hours ago

it seems very similar to just “git cloning”

Worktrees take less space, and the fetch/pull only has to be done once. It's a nice feature but restricted to workflows where you work on a lot of features at the same time.

[–] lobut@lemmy.ca 9 points 19 hours ago (1 children)

Yeah, I didn't see the use for them until I got further into it over just cloning. Your worktree "folders" share the same git history and stuff. So you can stash in one and apply in the other. If you do a fetch in one, it fetches for all of them.

Whether it's worth it for others to learn these just for those things is hard to say. I picked it up simply because I was bored and wanted to pick up a new "thing".

[–] Ephera@lemmy.ml 2 points 12 hours ago

Yeah, I think their saving grace is that they really aren't that hard to use. I don't use them often enough to remember the commands by heart, but it doesn't take me long to figure it out anew each time. Typically not as long as cloning the repo anew, at least.

[–] eager_eagle@lemmy.world 11 points 20 hours ago (2 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.

[–] Ephera@lemmy.ml 2 points 12 hours ago

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.

[–] ugo@feddit.it 5 points 20 hours ago* (last edited 20 hours ago) (1 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 3 points 19 hours ago (1 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 8 points 19 hours ago

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

[–] Static_Rocket@lemmy.world 4 points 18 hours ago

I use them all the time, but that's just because of Yocto and the need to keep at least the 3 major LTS builds hot in the event something breaks.

[–] tias@discuss.tchncs.de 4 points 19 hours ago

Unfortunately some developer tools fail to work correctly in separate worktrees. I used them for a while but had to give them up. For example, Maven's release plugin cannot reliably create tags / branches if you're in a separate worktree.

[–] JamonBear@sh.itjust.works 4 points 20 hours ago (1 children)

Worktrees are great, unless you have submodules...

[–] dessalines@lemmy.ml 4 points 20 hours ago

I use submodules for worktrees. You usually just have to run git submodule update --remote within any new worktree dir.

[–] FizzyOrange@programming.dev 2 points 18 hours ago (1 children)

Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don't work with submodules.

[–] HaraldvonBlauzahn@feddit.org 1 points 6 hours ago (1 children)

Which didadvantages of submodules did you find?

I see tree:

  • submodules make another repo's URL part of a repo. Thus, they couple source code with code and build hosting infrastructure, which is not good. For example it is not possible to clone a repo and its submodules to different host whithout forking the repo.
  • submodules are used for library-like modules of a codrme base. But they promote much stronger coupling than a proper backwards-compatible library API which is bad.
  • submodules are used to vendor libraries which is bad and in the end only cover up problems in build and packaging systems. Using the distributions package manager or a clean, powrful system like Guix would be better. Language-specific package managers are not as good a solution but still better than vendoring.
[–] FizzyOrange@programming.dev 2 points 5 hours ago
  • You have to tediously git submodule update --init --recursive every time you checkout a commit. There's an option to do it automatically but it's super buggy and will break your .git directory.
  • Switching between branches that have different sets of submodules doesn't really work. Git won't remove/recreate the submodules like it will for normal directories. Worst case is changing a directory to a submodule or vice versa.
  • If you're working on a feature that spans several submodules you have to switch branches in all of them instead of once.
  • Making co-dependant changes across submodules is a nightmare.
  • If you're using submodules for first party code (not uncommon), it basically creates a new public interface where you didn't have one before. Now you have to worry about backwards compatibility and testing becomes much harder. Monorepos don't have that problem.

The list goes on... Some of them depend on exactly what you're using them for.

The slightly frustrating thing is that there isn't a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren't any good languages agnostic package managers I know of.

I'm really hoping Jujutsu will come up with a better solution because it is possible. But it's hard, and they are constrained by Git compatibility so I won't hold my breath.