Using multiple working trees in Git
Tags: git, tutorial, productivity
Published: 2019-09-21 17:07:34

Have you ever found yourself cloning a git repository a second time, so you could work on different things? Or have you ever had to stash all your changes, or make a quick commit, so you could shift your focus to solving a bug that was just reported from production?

Whether you have found yourself in such a situation or you haven't (that time may come), it's always nice to know what the tools you use are offering.

## Git working trees
After initializing a local git repository, there is exactly one working tree. The one that was initialized by `$ git init` or by cloning the repository. At every given time, there is exactly one branch checked out within a local repository. 
That branch can still be changed at will, forth and back. But if you wanted to have two branches checked out at once, you could clone the repository a second time, into another directory, thereby downloading everything again. But this feels a bit cumbersome and maybe a bit too much, doesn't it?

### Adding another working tree
Luckily, git offers the feature of adding multiple (linked) working trees by not requiring another clone of a remote repository.

Within a local git repository, the following command adds a new working tree for an existing branch:

```zsh
$ git worktree add ../another-folder-for-your-new-working-tree branch-ref
```

After that, you have a new folder where you can point your editor or IDE to and work on an existing branch.
The new working tree is actually linked to your existing local repository and thus always synced. This means that nearly everything is shared between the original local repository and each working tree created and thus also saves disk space.

You could also directly check out a new branch within a new working tree:

```zsh
$ git worktree add --track -b a-new/branch ../another-folder-for-your-new-worktree origin/branch-to-branch-away-from

### for example:
$ git worktree add --track -b bugfix/foo ../project-x-bugfix-foo origin/master
```

### Cleaning up
If you want to clean up your working tree you can do it directly by calling
```zsh
$ git worktree remove ../folder-of-your-working-tree
```

Such working tree directories can also manually be removed. However, some administrative files, which reside within the actual repository, wouldn't be removed. But with the following command within the local repository:

```zsh
$ git worktree prune
```

you can still get rid of those now unnecessary administrative files easily.


## Conclusion
Linked working trees are a pretty great feature to have multiple stages, releases, or branches of your repository checked out at any time.
I use them all the time to reduce the time needed to switch between branches and also to sometimes keep a second (or even a third) instance of my editor up so I can more easily compare parts of code. They also help a lot when doing code reviews as the branch to review can easily be checked out and thus support the review process.
Just try it out and maybe working trees can help you to get more productive!

## More information
Check out the [official git documentation](https://git-scm.com/docs/git-worktree) if you want to find out more!

## Edit History
@joanis correctly pointed out that I placed `--b --track` in the wrong order. `--track -b` is the correct order. Within the post they are placed in the right order now!