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.
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”.
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.
git worktreeis just so much easier to work with if you want to work on multiple versions or branches of some code.It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.
Trying to emulate this with multiple clones feels like trying to do OOP in C – sure one can do it, but it’s pointless hassle compared to a fleshed-out solution that works right out of the box.
Not to mention it’s so much faster and more efficient than
git clone.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.
yeah, I think these are the main hurdles for me:
- 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:
- 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.
deleted by creator
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.
I don’t think anyone suggested that you add the .env symlink to the index. It should be ignored by git.
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.
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)
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.
This is pretty cool and solves one of the problems I’ve had whilst playing around with things like Cursor: that it breaks my flow having to wait 5-10 minutes for it to generate code/documentation, I’d really like to use that time to focus on my main work whilst it does some grunt work. Worktrees looks like it might provide a solution to this
Worktrees are great, unless you have submodules…
I use submodules for worktrees. You usually just have to run
git submodule update --remotewithin any new worktree dir.
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.
Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don’t work with submodules.
