How I Use Git Worktrees | Hacker News Reader

How I Use Git Worktrees

matklad.github.io

26 pointsnalgeon15 comments

Re "stash is bad" comment, I agree, but only if you're using git in CLI. If you use something like GitKraken, then you can visually see your stashes and it's pretty obvious what they're about. I find it easier to manage that way. But I definitely do the "just do a WIP commit on current branch then switch away" thing as well.

I've never used worktrees, but one thing I noticed from this post is that it adds an extra FS dir layer. This would break a few workflows at my company, we use relative paths to reference sibling git repos in certain situations (e.g. to run the server in one repo which servers a build sourced from the sibling frontend repo, etc). Knowing which worktree to use in that case wouldn't really work, those scripts using relative paths would need somekind of input/arg for the worktree name.

The relative path issue is a valid complaint. I have a script that can re-point references to sibling git repos to other worktree paths. However most projects, even those in development, tend to reference the master branch of any related dependent repo. If it becomes necessary to do some cross-repo development then I'm forced to keep that separate and explicit and I don't mind that.

This is similar to how I use worktrees. I have a worktree for the master/main branch; this is the current production branch. I have a worktree for test, which contains current branch deployed for testing. And I have worktree for doing new development.

If I'm doing new development and bug report comes in, I can just open the production project. I don't need to stop what I'm doing in my development branch at all. I don't have to worry about build artifacts or other details that come when you just switch branches in place. I also really dislike stashing.

I don't know why they aren't more popular.

If I had to guess, I’d say submodules. I work on a couple of projects with no submodules and find work trees great for those, but incredibly painful for the projects that have them. This seems to be getting better in newer git versions, but for a long time basic things like removing a worktree just flat didn’t work with populated submodules.

Submodules are such a pain in the ass. None of my own projects use submodules but when I work on open source projects they never seem to work as expected.

I am kind of curious to know how many people know and utilize git worktrees since it is fairly new (introduced in git v.2.28). I find it to be quite practical and your approach to git worktrees makes sense.

I've shared it at work before but I think you need to see something 5-10 times, then be motivated to try it, and then it really sinks in.

One neat feature I've also shown people is using worktrees to have many sparse checkouts from a big repo/monorepo so they can be used as more sane chunks.

git v2.28 was released four years ago almost to the day.

https://lore.kernel.org/git/xmqq5za8hpir.fsf@gitster.c.googl...

For anyone who wants to work on (non conflicting) changes at the same time, using a UI, I can recommend Gitbutler. Here you can check out multiple branches at the same time (e.g. do a development workflow at the same time as a bugfix). It is a little bit confusing at first, but I like it.

https://gitbutler.com/

Interesting. This is exactly my workflow, except I have 3 worktrees instead of 5: r/o remote, work and review.

I'm similar, though I have a helper script to quickly jump into a worktree for a branch, and then asks me to delete it when I leave. The main repo is for work, and the semi-temporary ones are review, remote, or whatever else I need.

The advantage of worktrees is to have only a single .git, instead of cloning it for every purpose, and also needing to update those separately.

> "ggc utility"

Does anybody know what this is? Google won't help.

* https://github.com/matklad/config/blob/a6ee2271a303fd4e6ea50...

Thanks for sharing!

Thanks for sharing:

``` TL;DR: consider using worktrees not as a replacement for branches, but as a means to manage concurrency in your tasks. My level of concurrency is:

main for looking at the pristine code,

work for looking at my code,

review for looking at someone else’s code,

fuzz for my computer to look at my code,

scratch for everything else!

```

Reply on news.ycombinator.com