Worktrees!
Did you know about Git worktrees? If not, today’s as good as any to get to know them. Especially so since they are ridiculously simple and powerful at the same time.
To put it simple, worktrees are just additional working copies of an existing, cloned repository. When you clone a repository and checkout a branch, Git creates a working copy - the actual files and directories you’re working on. These files are all just copies of data in your local Git repository, conveniently brought into file-form to be able to work on them (hence the name). Worktrees are the logical extension of this idea - instead of one working copy for one Git repository, you can have an arbitrary number of such copies.
But Why?
Say you’re working on a long-lived branch of a big software project. Building it takes quite some time, even opening the project in your IDE of choice is something you’d rather not do too often. But that long-lived branch is not the only thing you’re working on. Occasionally you’re fixing a bug here, implement a simple feature there, maybe build some older version of the software to validate some assumptions, …
All this requires you to switch between different versions (let’s say commits). But doing so in your working tree messes up your build artifacts. Your IDE will probably need to reload the project, files will need to be rebuilt. You may even run into other issues depending on the tools used. While you can clone your project multiple times, keeping all those clones in sync with upstream is just tedious. And if you want to move commits between these two working trees, it gets messy quite fast. Not to forget that all these clones could take a lot of space as well.
Worktrees solve all of this. You get independent working copies which still share their history, locally. This way, some of your work can stay in progress without getting in the way of other tasks. Nice.