A while ago I encountered the idea of using git worktrees for various branches instead of a single git workspace with stash and switch branches. I found the idea appealing for a number of reasons, but found that there are advantages and disadvantages to both approaches.
A bit of explanation of both methods.
Two Approaches to the problem of concurrent work on multiple branches
| Single Worktree |
Separate Git Worktrees
|
| A user might have just one, or several complete clones of a set of repositories. Each of these clones would have a single worktree. If working on multiple branches the user might simply do the work on a separate set of clones, or they could use a single set by using git stash to move between branches.
|
Reasons for adoption of one approach or the other might include
- A need to quickly produce separate builds for next, stable and lts versions
- A need to work on changes to multiple branches in parallel
- Comple
Advantages
| Single Worktree |
Separate Git Worktrees
|
| Good for doing one thing at a time |
Multitasking
|
| Simple to change context: move to a different directory, or stash current branch work, switch branches as needed and continue |
Multiple contexts are all set up and ready to go
|
| Less to keep track of |
|
|
Faster Context Switching
|
|
Worktrees take up less space than a
|
| Sequential Builds |
Parallel Builds
|
| 1 script sets up your environment. It's all you need. |
Configuration file covers multiple working contexts in an easy to read format
|
Disadvantages
| Single Worktree |
Separate Git Worktrees
|
|
Manually track all the contexts in which you wish to work || More active contexts - You'll need tools to manage the complexity
|
| When the work gets complex, managing it manually becomes harder |
Definitely more complex, but then it supports very complex needs.
|
| Multiple full copies of repositories in some situations |
Requires some configuration to avoid manually setting up each working context.
|