I use git worktrees daily. I'm surprised by how hard it can be to explain them to people who have never used them. Lately I've settled on "like clones, but sharing a .git directory." The article tries to get this across by comparing them to branches, but I think clones are a more intuitive concept to compare against.
To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/
Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.
The one real caveat to this is that if your application has particularly heavy cold starts it can be hard to actually run your worktrees. I usually end up swapping to a regular checkout as each worktree is due for hands-on attention.
Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use said url. While you could get the same benefit from cloning your local repository, you're then in the weird state where `origin` is a local non-bare repository.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.
It makes coordination easier. For eg if you want to fetch and pull master, you only have to do that once. If you want to rebase checkout A's branch on top of B's, you can just do that, you don't have to push between the two.
I use git worktrees daily. I'm surprised by how hard it can be to explain them to people who have never used them. Lately I've settled on "like clones, but sharing a .git directory." The article tries to get this across by comparing them to branches, but I think clones are a more intuitive concept to compare against.
To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/
Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.
Fossil SCM, conventionally, has been thus way by default.
https://fossil-scm.org/home/doc/trunk/www/gitusers.md
wt is a useful little tool for helping with git worktrees: https://github.com/timvw/wt
I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.
The one real caveat to this is that if your application has particularly heavy cold starts it can be hard to actually run your worktrees. I usually end up swapping to a regular checkout as each worktree is due for hands-on attention.
I'm curious what the constraint preventing you from optimizing the cold start time - can you share more?
This is very interesting and could be very helpful for A/B testing or comparing outputs/speed between 2 branches.
I already know a place I want to use this.
I do the same thing just checking out the repo multiple times in different directories.
I'm not really sure what worktrees adds on top of that.
Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use said url. While you could get the same benefit from cloning your local repository, you're then in the weird state where `origin` is a local non-bare repository.
If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.
It makes coordination easier. For eg if you want to fetch and pull master, you only have to do that once. If you want to rebase checkout A's branch on top of B's, you can just do that, you don't have to push between the two.
Less space.
What a peculiar title. The title suggest parallel dev without using worktrees, but the article is about using worktrees.
I thought that as well and then realized I had inserted the word "of" before "using" where there's an implied "by."