I read Github's post on git-worktree. They write:
Suppose you're working in a Git repository on a branch called
feature, when a user reports a high-urgency bug inmaster. First you create a linked working tree with a new branch,hotfix, checked out relative to master […] You can fix the bug, push hotfix, and create a pull request.
When I'm working on a branch called feature and some high-urgency bug in master is reported, I usually stash away whatever I'm working on and create a new branch. When I'm done, I can continue working. This is a very simple model, I've been working like that for years.
On the other hand, using git-worktree has its own limitations:
For example, it's not allowed to have the same branch checked out in two linked working trees at the same time, because that would allow changes committed in one working tree to bring the other one out of sync.
Why would I choose a more complicated workflow for a problem that's already been solved?
Is there anything about git-worktree that couldn't be done beforehand and that justifies this whole new, complex feature?
For me, git worktree is the biggest improvement since a long time. I'm working in enterprise software development. There, it is very common that you have to maintain old versions like what you released 3 years ago. Of course you have a branch for each version so that you can easily switch to it and fix a bug. However, switching is expensive, because in the meantime you completely restructured the repository and maybe build system. If you switch, your IDE will run mad trying to adapt the project settings.
With worktree, you can avoid that constant reconfiguration. Checkout those old branches in separate folders using worktree. For each branch, you got an independent IDE project.
Of course this could have been done in the past by cloning the repo several times and this has been my approach so far. However, that also meant wasting hardrive space and worse needing to fetching the same changes from the repo several times.