Git worktrees are now cool

[This article was first published on Maëlle's R blog on Maëlle Salmon's personal website, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

I’m not mad when current AI tools or tips1 make Git look cool and important. Something old and stable to cling to! 🤗 In particular, it’s now trendy to have agents work on different tickets in the same project in parallel by using Git worktrees. Git worktrees are even useful for us humans, even if we should probably not work on a dozen things at the same time.

I had learnt about Git worktrees a while ago, but only viewed them as a way to open a read-only view of a past version of a repository: I have written about loading different R package versions at once with git worktree. The exercise about worktrees I added to the saperlipopette R package is very much about reading too.

Let me sum up what I learnt about Git worktrees in the last weeks…

Git worktrees are for any work, not only reading

Let me first admit I have trouble getting used to the idea of a “working tree”. What Git calls a “working tree” I call “my files” (my precious files). But knowing what a “working tree” is makes it easier to get used to a “worktree”, which is a working tree with some metadata.

You can init/clone your Git repository once and then from there sprout as many working trees as you need. Only the main one has a fully-fledged .git folder, the others have a .git file with a line like “gitdir: /path-to-the-main-worktree/.git/worktrees/current-worktree” in it.2 But from any worktrees you can run any Git commands. You can for instance:

  • have a worktree where you fix a bug and another worktree where you write docs.
  • create commits and push from either one.

From reading Julia Evans’ bonus comic about Git worktrees, I learnt that an advantage of using worktrees rather than cloning the same repo several times is that it’s faster, because of the worktrees’ sharing a .git folder.

Creating a worktree for a brand-new branch is easy

If you want to create a new worktree for a new branch feat-bla, do not run

git branch -c feat-bla
git worktree add ../feat-bla feat-bla

You can simply run:

git worktree add ../feat-bla

I learnt that from reading the manual page for git worktrees, who’d have thought reading docs was useful? 🫠

Conclusion

Git worktrees are cool, and they’re not even fancy, even if your AI service or orchestrator might manage them for you. They’re sort of a… low-hanging fruit I guess. 🙊


  1. For instance, the post “Becoming an AI-proof software engineer” by Iris Meredith states “Being an effective user of git makes software development much less painful and importantly allows you to collaborate with other developers”. It also recommends writing. 😸 ↩︎

  2. I am very proud of having gone inside .git to prep this post. 🫡 ↩︎

To leave a comment for the author, please follow the link and comment on their blog: Maëlle's R blog on Maëlle Salmon's personal website.

R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Never miss an update!
Subscribe to R-bloggers to receive
e-mails with the latest R posts.
(You will not see this message again.)

Click here to close (This popup will not appear again)