Git Worktree: Parallel Development Without the Headaches
Parallel development without the headaches using Git worktree
Learn how Git worktree lets you check out multiple branches in separate directories, sharing the same repository history. This guide covers creating, merging, and removing worktrees, with a practical example of juggling a feature and a hotfix. Discover how it reduces context switching and keeps your work organized.
It keeps all the elements compartmentalised, reduces context switching and means stashing has become a rare exception.
- tlarkworthy
I use a top level meta-repository to create a virtual monorepo of all my repositories and vendor their upstreams, then use worktrees off off the submodules to prepare patches. I never need to change directory from the root meta-repository even with multiple agents. Gives you a full monorepo experience without actually having to own any of the parts, every agent has its own isolated worktree so does not conflict.
- zmmmmm
The real problem for parallel dev is ensuring parallel dev environments can seamlessly co-exist without treading on each other. As soon as one of them wants to open a port, talk to an external database or write to a shared location as part of testing you have them conflicting with each other.
Much of this is a legacy dev issue where there was never so much of an assumption that parallel ephemeral dev environments would be in play in the first place. But legacy dev is still most of dev.
- therealmarv
Maybe I'm stubborn, but even in the age of AI, I still use multiple git clones/directories of the same project, e.g.:
~/dev/projectx
~/dev/projectx2
~/dev/projectx3
~/dev/projectx4
very rarely use more than 4–5 per project. Maybe I'm just avoiding wrapping my head around worktrees and actually trying them out.
Benefits: These clones act as semi-permanent directories:
- Helps with caching for heavy Docker usage (think of repeated parallel unit, e2e tests)
- I've color-coded my terminal tabs for each clone so I can instantly tell where I am at a glance (kinda like tab groups just with colors)
Maybe if for some reason I need double digits clones of a project I will be more forced to use git worktrees because then it will be annoying to remember in which directory a branch clone lives.
- irskep
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.
- pkghost
Having gone down the worktree rabbit hole for a month or so, I am giving up in favor of multiple checkouts to enable many agents to work across many repos.
Worktrees worked great for me when my agents' work was mostly contained to a single repo (they got me to finally hitting rate limits, not that that was a goal). As my homelab scales, agents increasingly work across multiple repos, and that's where (my approach to) worktrees broke down; agents were spawned in a repo worktree and so avoided stepping on the toes of other agents in the same repo without any special instruction, but as soon as they needed to touch another repo, they would default to working in that repo directly, without a worktree, and thus collide with other agents, and muddy a merge process that expected the main repo clone to be clean (which turns out to have been an unnecessary design quirk, but resolving it would still not stop agents from stepping on each other's toes in secondary repos).
After a detour through ZFS dataset clones and some mounting magic that made /srv/src/ appear to be a distinct hierarchy for each agent process, I am simplifying even further and giving each agent a bare directory (sth like /srv/dev/<slug>/) where they can check out any repos they want. The git remote (/srv/git/) becomes the only integration point.
Maybe I should just bite the bullet and move into containers, but performant as they are the ergonomics still bum me out.
Edit: I may actually hold on to ZFS datasets with mou […]