I'm a C++ dev, I have one checkout of the main repo and 3 worktrees. Switching branches can be expensive because of recompiles, so to do e.g. quick fixes I'll use worktree 1 where I typically don't even compile the code, just make the fix and push it to the CI system. Worktrees 2 and 3 I keep at older releases so I can immediately fire up development and one of those releases side by side and compare results as well as the code.

The cool thing about worktrees instead of multiple checkouts is that you only have one .git folder, so less disk space. But more importantly local branches (well everything actually) are shared, so you can create a local branch in the main checkout, and later come back to it in a worktree. You also don't need fetching/... in the worktrees, as they share the same .git folder.

Only thing that I found virtually impossible to work with is worktree + submodules.

I'm imagining a scenario where you're working on a feature that changes the DB state (e.x. introduces a new DB migration that changes some columns) and the bug is on an unrelated part of the code from your feature. In this hypothetical, going back to the state of the upstream branch would make your local environment non functional, and the bug is on an unrelated part of the code. Fairly specific scenario but hey, you can worktree for that. It's not particularly thorough, though.

A monrepo is another good reason (besides those mentioned). When switching branches changes hundreds of files, it's not so quick or slick anymore.

A commit followed by a reset or commit --amend later is one more step than a worktree --add. Plus there have been lots of times when I've had some changes staged, and some unstaged debugging or experimental changes that I want to make sure not to commit, and thinking about how to pack all that away neatly so I could get back where I was seemed sufficiently obnoxious that I avoided doing whatever would have required a quick branch switch. Worktree would have let me pick up where I left off without having to think about it.

Recently I had to do an update to the underlying environment a codebase ran on. This was a somewhat involved upgrade and took a longer period of time than most of our work usually does. I did it in a separate worktree, so I didn't have to constantly rejuggle the installed dependencies in the project, and could work on two features relatively concurrently

It also provides some utility for comparing the two versions. Nothing you couldn't do other ways, but still useful

• Scenario: I'm in the middle of writing a new feature.
• Boss, to me: "Shit broke. Go figure it out."
• Me, thinking: I'm in the middle of doing some complex work. If I commit/stash and close the open files, it will take a day for me to remember WTF I was doing.
• Me: "Oh look, worktrees! I can leave my workspace intact with all the files open, pending changes, test results, terminal output, everything! And just create a new worktree to checkout the production version and debug! I'm saved!"

Also setting up a worktree is really easy. git worktree add ../hotfix prod-branch && cd ../hotfix and get working. Though in reality it's cd ../hotfix && git checkout prod-branch because I've never needed more than one secondary worktree.

Because you'd have to stash your modifications to be able to switch branch. The stash is a stack so very limited in what it can do (just push and pop). You might prefer to commit on a temporary branch instead. But you might also need some parts from your current modifications for the bug fix, at which point having it taken away on another branch or in stash won't do. I would usually end up resorting to doing another checkout side by side anyway, and if I can make it a sparse checkout it's even better.

Because spending 1h+ recompiling everything whenever a colleagues points out a typo in a merge request is a waste of time