July 25th, 2024

How I Use Git Worktrees

The author advocates for using Git worktrees to manage multiple coding tasks concurrently, highlighting their benefits over branches for context switching and productivity in software development.

Read original articleLink Icon
How I Use Git Worktrees

The article discusses the author's approach to using Git worktrees, emphasizing their utility for managing concurrent coding activities rather than as a direct replacement for branches. The author initially used worktrees similarly to branches but found that this method did not suit their workflow. They highlight the challenges of context switching with branches, particularly the difficulties in managing the staging area and stash. Instead, the author prefers to commit changes frequently and switch branches as needed, using a utility script for efficiency.

The author maintains five worktrees, each corresponding to different coding activities: a readonly worktree for comparing code with the main branch, a worktree for active coding, a review worktree for code reviews, a fuzz tree for running fuzzing jobs, and a scratch worktree for miscellaneous tasks. This setup allows for concurrent work on different tasks without losing context. The author provides a detailed workflow for creating branches, committing changes, and running fuzz tests, illustrating how worktrees facilitate multitasking in coding projects. They conclude by suggesting that worktrees can enhance productivity by allowing developers to manage multiple tasks simultaneously, rather than merely serving as an alternative to branching.

Related

I kind of like rebasing

I kind of like rebasing

People debate Git workflows, favoring rebasing for a linear history. Redowan Delowar prefers rebasing to consolidate changes and maintain a clean commit history. They discuss interactive rebasing benefits, squashing commits, handling conflicts, and offer practical tips.

My .gitconfig File Dissected

My .gitconfig File Dissected

The article delves into .gitconfig file breakdown, covering user details, GPG key signing, Git aliases, and workflow optimization tips. Encourages readers to customize their .gitconfig for enhanced Git usage.

Things I know about Git commits

Things I know about Git commits

The article delves into Git commit insights over 12 years, stressing well-crafted messages, rebase-merging benefits, atomic commits, and effective documentation. It highlights commit messages' impact on collaboration, code maintenance, and project management.

Working with stacked branches in Git is easier with –update-refs (2022)

Working with stacked branches in Git is easier with –update-refs (2022)

The new Git feature, --update-refs in version 2.38, simplifies rebasing stacked branches by automatically updating branches pointing to rebased commits. It enhances efficiency and management of Git workflows.

Async Git-stash workflow enables test test-driven development

Async Git-stash workflow enables test test-driven development

This blog post explores an async Git-stash workflow for test-driven development, showcasing top-down system and component development with asynchronous features and dependency storage using Git stash. It provides a C++ library example for DeepThought computer development, highlighting the significance of test-driven development and asynchronous workflows.

Link Icon 9 comments
By @francislavoie - 4 months
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.

By @wvenable - 4 months
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.

By @Ivan92 - 4 months
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.
By @clemsen - 4 months
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/

By @frizlab - 4 months
Interesting. This is exactly my workflow, except I have 3 worktrees instead of 5: r/o remote, work and review.
By @vitaminCPP - 4 months
> "ggc utility"

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

By @heyrikin - 4 months
Thanks for sharing!
By @snthpy - 4 months
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!

```