What would I use git-worktree for?

Question

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 re

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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