Working within Multiple Git Branches Simultaneously

In Git, the git checkout command is used to switch between branches. In addition, if some work is incomplete but in progress, a common practice is to use git stash to temporarily stash changes away before switching branches.

However, when working on multiple branches of development simultaneously, there is often more involved than just stashing half-completed work away or switching the currently active branch. Some code may need to be re-configured and/or re-compiled; maybe a lot of it. This is particularly true for projects which are sensitive to timestamp changes of any build tree dependencies. Resulting delays can create a productivity issue.

A common approach is to git clone the same repository multiple times and then set each clone to a different branch. It is even possible to keep local clones synchronized (without going through their common origin) using git remote add <name> <local-path> and git fetch <name> (where <local-path> is the local directory path to another local repo clone). However, this involves multiple copies of the git repository which may have negative implications for disk space or workflow.

Alternatively, you may find git worktree a better approach than multiple clones and a useful productivity boost. Git worktrees allow you to work as if you have multiple clones without having to make explicit cloned copies, saving disk space and perhaps easing any workflow issues. A single .git database, including local hooks and other settings for example, manages all the worktrees. The advantages of Git worktrees over clones multiply as the number of concurrent branches to be managed grows. On the other hand, if it is necessary to manage different repository settings (e.g. hooks, file ignores) across concurrent branches, multiple clones may be the only solution.

Finally, although git worktree has been available in Git since 2015, it is still considered an experimental feature and doesn't work with Git submodules.