Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
www.tomups.com
Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
20 comments
-
-
Seems handy, but all the typical git caveats apply:
- "Here's a cool feature! NEVER USE IT THIS WAY OR YOU'LL RUIN YOUR WORKING DIRECTORY!"
- Here's a cool feature, it's actually old and has no standard usage so everyone you meet will be subtly misusing it differently
- Here's why you should use my workflow instead of yours: Demonstrates a process with 2 less steps but also he skips the cleanup steps so actually its the same amount of work
Fossil also supports this out of the box: you can have as many checkouts of a repo as you want against different branches, and it tries to prevent you from accidentally nesting repositories instead of opening new checkouts.
-
What benefits does this provide over a cloned copy of the repository?
-
It's more space efficient - you don't get another full copy of the repo. The worktree points back to the same .git directory.
And since it's in the same repo you can diff between branches with other worktrees without needing to setup remotes for each of them.
-
No need for another full git history copy, nor submodules and settings.
-
-
😄 i could have used that at the project we just finished up 🤭 it is a nice idea, having master always ready in separate worktree to keep it up to date, so that you alwys can rebase your fix or feature branch onto it
😂 I always switched to master, pulled, switched back and then did the rebase
I am obsessed in having all commits of master in my feature branch 😆
-
I tried using them a while back but I stopped and nowadays I just reclone. Worktrees do not work with submodules, and the setup is fragile so it’s easy to screw up your .git if you’re not careful. It’s also more trouble than it’s worth having to juggle branches if it turns out one of your worktrees is checked out at the same point you want to checkout another one
20 comments
As somebody who rarely has a "pristine" working copy I love worktrees. I usually have a "project-master" worktree that's a pristine checkout of the
masterbranch so I can test builds and things without interference from uncommitted and temporary files.Same. The main thing I've been liking about it for the slower compiling languages that I mainly work in (rust, android jetpack compose), is that it leaves the
buildortargetdirectories in place. So instead ofgit checkout && clean_build_dir, and having to wait to recompile, I can justcdto that dir.I usually just check out another copy in another directory, say I am working on Foo.
foo/is the dev playground andclean-foo/for a clean checkout from master.I know you can do it all with commands but I just find it easier to diff between directories or check how things are in master without touching the dev dir.
When you do that you can't compare branches in the same working copy in different directories. You need to create remotes between the two working copies and push/pull between them.
e.g. "git log --graph ..my-branch" or "git diff my-branch master" where my-branch and master are in different directories.