You probably don’t need git worktrees

Like a lot of developers right now, I’m figuring out how to support a “supervising several parallel development efforts at once” workflow. If you look for information on the web about how to implement a workflow like this, you’ll see a lot about git worktrees—where a single .git directory serves multiple working checkouts on different branches in different base directories.

But worktrees have some significant limitations. Not least of which is that their dependence on hardcoded fully-qualified paths written into configuration files not only makes worktrees non-portable, but also makes them DOA for any kind of containerized development environment. The worktree.useRelativePaths option helps here, but as of this writing it’s still relatively brand-new (Git v2.48 released Q1 2025), and not available in the version of git you probably have installed on your host machine or any of your container images. On top of that, VSCode’s support for relative worktrees with devcontainers is experimental, totally undocumented, and (as of this writing) unreliable at best.

Here’s what I didn’t realize until this week: you don’t need worktrees at all!

It’s 2026. Internet bandwidth is fast and disk space is cheap. But! Guess what: you don’t even need to fill up your disk with duplicate repos, or wait for lengthy git clone operations from origin every time you need a new branch-dedicated workspace.

That’s because when you do a local clone:

git clone my-project my-project.my-branch-a
git clone my-project my-project.my-branch-b

…not only is it near-instantaneous, it also doesn’t take up significantly more disk space! Why? Because by default, Git makes hard links for the object files when locally cloning a repo! Object files are immutable hunks of history, so there’s no reason not to share them across repositories on the same volume.

You’ll need to do a little bit more than this: you’ll also want to rewrite the new clone’s origin remote to point to the original origin rather than the source directory. I tasked a robot with making me some git-extension convenience scripts, so for instance I can exec git bc-add my-project my-branch-name to clone, massage remotes, and either checkout or create the branch in one command. You can do whatever streamlining makes the most sense for your process.

The important part is that local git clones are fast and cheap. So don’t worry about worktrees. Just clone and get coding!

Leave a Reply

Your email address will not be published. Required fields are marked *