Using multiple working trees in Git

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:

$ 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:

$ 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

$ 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:

$ 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 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!

Comments

[Simon Massey]

Amazeballs! Thanks

[Oliver Jumpertz]

I'm glad you like it :-)

[Arpit Mohan]

I was today years old when I learnt about worktree! This command is definitely going into my tool bag.

[Cameron McKenzie]

lol. I wrote an article about Git worktree add when I discovered it and opened the article with the exact same line: "I was today years old..."

[Maxime Joanis]

Didn't know about this, good stuff! Thanks!
I'm trying it out and it seems it won't work unless I put the branch directly after -b.
Commands starting with git worktree add -b --track
Should probably read git worktree add --track -b

[Oliver Jumpertz]

Whoops, you are absolutely right. I'll correct this right away. Thank you for pointing that out!