What would I use git-worktree for?

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 reports a high-urgency bug in master. First you create a linked working tree with a new branch, hotfix, checked out relative to master […] You can fix the bug, push hotfix, and create a pull request.

When I'm working on a branch called feature and some high-urgency bug in master is reported, I usually stash away whatever I'm working on and create a new branch. When I'm done, I can continue working. This is a very simple model, I've been working like that for years.

On the other hand, using git-worktree has its own limitations:

> For example, it's not allowed to have the same branch checked out in two linked working trees at the same time, because that would allow changes committed in one working tree to bring the other one out of sync.

Why would I choose a more complicated workflow for a problem that's already been solved?

Is there anything about git-worktree that couldn't be done beforehand and that justifies this whole new, complex feature?

For me, git worktree is the biggest improvement since a long time. I'm working in enterprise software development. There, it is very common that you have to maintain old versions like what you released 3 years ago. Of course you have a branch for each version so that you can easily switch to it and fix a bug. However, switching is expensive, because in the meantime you completely restructured the repository and maybe build system. If you switch, your IDE will run mad trying to adapt the project settings.

With worktree, you can avoid that constant reconfiguration. Checkout those old branches in separate folders using worktree. For each branch, you got an independent IDE project.

Of course this could have been done in the past by cloning the repo several times and this has been my approach so far. However, that also meant wasting hardrive space and worse needing to fetching the same changes from the repo several times.

I can see some uses for this.

If you have a test suite that runs for a long time, imagine hours, and you start it it effectively blocks that working copy until the tests are completed. Switching branches during those tests would break them in ways that would be hard to understand.

So with git-worktree I could have a second idea launched for another branch doing work there.

Also, when I switch to some other branch to do some quick investigation my IDE thinks a lot of files suddenly changed and will index all those changes, just to have to re-index them again when I'm switching back.

A third use case would be to do file comparison using other tools than git-diff, like normal diff, between two directories instead if two branches.

One obvious use is to simultaneously compare the behavior (not source) of different versions - for example different versions of a web site or just a web page.

I tried this out locally.

• create a directory page1.

• inside create the directory src and git init it.

• in src create page1.html with a little content and commit it.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• in src master add more text to page1.html and commit it.

• $ git branch sty1

• edit page1.html in the sty1 branch (add some distinctive CSS style) and add commit it.

• $ git worktree add ../S1 sty1

You can now use a web browser to open and view these 3 versions simultaneously:

• ..\page1\src\page1.html // whatever git has as current

• ..\page1\V0\page1.html // the initial version

• ..\page1\S1\page1.html // the experimentally styled version

1. 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.

2. 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:

   1. 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.

   • Running 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.

   2. You can share refs between worktrees. If you want to compare or borrow changes from another local branch, now you can.

My absolute favorite and probably the most common use-case where everyone should use git worktree is reviewing the pull requests of team-mates, while still working on your changes in the main worktree. 

tl;dr: Any time you want to have two work trees checked out at the same time for whatever reason, git-worktree is a quick and space-efficient way to do it.

If you create another worktree, most parts of the repo (i.e. .git) will be shared, meaning if you create a branch or fetch data while you are in one work tree, it will also be accessible from any other work trees you have. Say you want to run your test suite on branch foo without having to push it somewhere to clone it, and you want to avoid the hassle of cloning your repo locally, using git-worktree is a nice way to create just a new checkout of some state in a separate place, either temporarily or permanently. Just like with a clone, all you need to do when you are done with it is delete it, and the reference to it will be garbage collected after some time.

I originally stumbled on this question after wondering what these fancy worktrees could be used for. Since then I have integrated them into my workflow and in spite of my initial scepticism I have come to find them quite useful.

I work on a rather large code-base, which takes quite some time to compile. I usually have the current development branch on my machine along with the feature branch I am currently working on plus the master branch, which represents the current state of the live system.

One of the biggest benefits for me is obviously that I don't have to recompile the entire thing everytime I switch branches (that is, worktrees). A nice side-effect is that I can go to the development worktree, do stuff there, change directory to the worktree for my current feature branch and then rebase it without having to pull first.

I've got a rather unusual one: I am doing Windows and Linux development on the same machine. I have a VirtualBox running Linux inside of my Windows box. The VirtualBox mounts some Windows directories and uses them directly inside of the Linux machine. This lets me use Windows to manage files but build within Linux. This is a cross-platform project, so it builds on both Windows and Linux from the same directory structure.

The problem is that the Linux and Windows build systems crash into each other when used in the same directory; there are some complicated build steps for downloading libraries, etc., that use the same directory names. The Windows version of the build system downloads the Windows-specific libraries, and the Linux version of the build system downloads the Linux-specific libraries.

In an ideal world, the build system would be modified so that Windows & Linux can co-exist within the directory, but for now, the problem is being addressed with worktrees. The "Linux" folder can generate Linux-specific build artifacts, and the "Windows" folder can generate Windows-specific build artifacts. While this is hardly an ideal solution, it makes a nice stopgap while waiting for the build system bugs to be addressed.

Admittedly, worktree wasn't designed for this; I have to keep the Windows version and the Linux version on separate branches, even though I'd really prefer them to be on the same branch. Still, it's doing the job, and is a somewhat unconventional case of worktree saving the day.

I'm using git worktree for machine learning development.

I have a main functional code and then I want to split branches of different experiments (different algorithms and different hyperparameters). git worktree allows me to integrate dvc alongside different versions of my code specialized to different algorithms. After running all training jobs I evaluate final metrics and merge to master the best branch/model.

In new project for me, I've created a feature. But some specs failed. To compare results with master I created a work-tree repo. I compared results step by step in run code, until understand what went wrong.