RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
50% Positive
Analyzed from 598 words in the discussion.
Trending Topics
#worktrees#git#clones#more#project#dev#multiple#directory#worktree#checkout

Discussion (15 Comments)Read Original on HackerNews
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.
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.
https://fossil-scm.org/home/doc/trunk/www/gitusers.md
I use it's config to copy in some non-repo config and then hooks to start an agent doing analysis.
I already know a place I want to use this.
I'm not really sure what worktrees adds on top of that.
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.