Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
www.tomups.com
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
22 comments
-
-
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.
-
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)
-
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
-
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.
-
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, unless you have submodules...
-
I use submodules for worktrees. You usually just have to run
git submodule update --remotewithin any new worktree dir.
-
-
Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don't work with submodules.
-
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.
-
- You have to tediously
git submodule update --init --recursiveevery time you checkout a commit. There's an option to do it automatically but it's super buggy and will break your.gitdirectory. - 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.
- You have to tediously
-
22 comments
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.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.