Cover photo by Lucas van Oort on Unsplash
My struggles
I can't count how many times this happened to me while working on a project: I am in the middle of developing a feature on a branch and I need to switch to another branch to make some modifications (maybe a change asked in a review, forgot something in my submission, etc.). I git stash
my current work, I switch branch and I do some work. I often get carried away by having to work longer than anticipated on that other branch or I jump on a quick call with a colleague or whatever. I come back to my initial work and two situations often happen: I forgot I stashed code so I get a little scared for 10 seconds when stuff is missing/broken or there is some weird state that prevents me from switching back to my initial branch.
I always had a love/hate relationship with git stash
for those reasons. I learned I was not the only one when discussing it with colleagues. One of them shared with me what he does: do a temporary commit, switch branch, come back to the original branch and revert back before that faux commit. Another way of doing it but I am not a fan for some reasons: you can still forget to revert back, there is no "traces" of it if you don't check the history (similar to git stash
if you don't list them) and you can potentially shoot yourself in the foot when reverting back to a commit.
How does it work
When using git clone
or git init
with non-bare repos, there is a main worktree created in the folder with the main
branch checked out. Everything that is not .git
inside the current folder is the main working tree. I have heard developers call that the working space, the current workspace but the correct term is a working tree.
Enters git-worktree
: this command lets you create additional working trees called linked worktree
. You specify a folder and git-worktree
will create a linked worktree inside of it so you can checkout any existing or new branch inside of it. All you have to do then is cd
into that folder and you are now working on another branch, on a workingtree parallel to the main one. No more getting confused or messing up things.
How I use it
In a project folder, I create a worktrees
subfolder and inside of it I create a folder named after the branch I want to checkout inside that new linked worktree.
Some use cases for the command
- You have tests that take a while to run but you can't switch to a branch because that would change files and introduce unwanted behaviors.
- You are working on a feature and need to hop on another branch to fix some code on a submitted merge request but there is uncommitted work.
- You want to try something quick while working on code you don't want to lose.
Getting started
Here are some useful git-worktree
commands from the npm tldr page:
Next step
I would like to fully use git-worktree
with Docker. I will explore possibilities on having different containers running in parallel from different worktrees without having to manually change the docker-compose.yml
ports. Hit me up if you have a found a solution to this.
Conclusion
git-worktree
allows us to work on multiple branches in parallel without forcing us to commit or stash between checkouts. I am more than happy to ditch git stash
and to never look back.
I am always eager to learn from others so let me know how you work with git-worktree
or in which scenarios it is helpful to you. Maybe you have an even better solution?
Top comments (9)
This is pretty much what I do. Every new project gets a new worktree in the wt subdir of the repo named after the branch I am working on. All I need to do to switch projects is cd - no worry about what files will be stashed, what I lose in a branch switch, etc. In fact I have wrapped all of this in scripts that keep track of all these directories so that I type
git go
to get a list of them in a SELECT menu andgit go <regexp.
to filter the choices,The script is a very good idea and it gives me inspiration. Do you use bare repos?
Nope. I have a LARGE set of git wrappers such that when I type:
~/gits/github/org/repo
~/gits/github/org/repo/wt
.Then I
git go somerepo
to cd to~/gits/github/org/repo
and typewhich
foobr
branch./wt
foobr
directoryfoobr
worktree, usingfoobr
branch in thefoobr
directoryIt's a hairy complicated mess that has grown over the past 7 years. The key to it all is that I have a function called
git
. Yep. I do my OWN dispatch. Otherwise, you can't add to existing git commands.If you want to see it: github.com/matthewpersico/personal
That's a kinda neat solution and if that works for you that's good.
Yeah. I keep thinking about breaking it out into its own repo,but it’s just too intertwined with lots of my utility stuff. And, it could probably use a rewrite in Python or Perl for most of the gymnastics it does in shell with git hub api. But who has the time? I cobbled it together over 7 years at my $job.
Loved it.
Thanks! I will update it soon enough since I've been using worktrees for a while now. What changed most is that I avoid having worktrees directly in the project folder where the
.git
folder is.Great article mate!
Thanks, your comment really means a lot to me!