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 re
There are legitimate reasons why you may want/need multiple worktrees in the filesystem at once.
manipulating the checked out files while needing to make changes somewhere else (eg. compiling/testing)
diffing the files via normal diff tools
during merge conflicts, I often want to navigate through the source code as it is on source side while resolving conflicts in the files.
If you need to switch back and forth a lot, there is wasted time checkout out and rechecking out that you don't need to do with multiple worktrees.
the mental cost of mental context switching between branches via git stashing is not really measurable. Some people find that there is mental cost to stashing that isn't there by simply opening files from a different directory.
Some people ask "why not do multiple local clones". It is true that with the "--local" flag you don't have to worry about extra disc space usage. This (or similar ideas) is what I have done up to this point. Functional advantages to linked worktrees over local clones are:
With local clones, your extra worktrees (which are in the local clones) simply do not have access to origin or upstream branches. The 'origin' in the clone will not be the same as the 'origin' in the first clone.
git log @{u}.. or git diff origin/feature/other-feature can be very helpful and these are either not possible anymore or more difficult. These ideas are technically possible with local clones via an assortment of workarouns, but every workaround you could do are done better and/or simpler through linked worktrees.You can share refs between worktrees. If you want to compare or borrow changes from another local branch, now you can.