Git Worktrees Tutorial #1 - What are Git Worktrees?

Key Takeaways

All right then, my friends. In this series, we're going to be diving into a Git feature that's been around for a long time, Git Work trees, but they've only recently started gaining traction on YouTube thanks to a flurry of AI content. And from what I've seen of some of those videos, I feel like a lot of them don't really dig into the details of what Git work trees are and why they're useful outside of the scope of agentic coding. So, in this series, I want to dive a little bit deeper, show you a couple of different ways we can work with git work trees, and then at the end of the series, I'll make a video about why they're being used so much in aentic coding setups as well. And hopefully that gives you the context you need. So, let's start by talking about what work trees are and what problems they solve during a typical development workflow. Now, just very quickly before you start, I want to say that if you don't already know the basics of Git, then you should definitely start there. So, if you want to learn Git from the beginning, I've got a big Git and GitHub master class available, which I will leave a link to down below the video. I've also added this whole Git Workree series to the end of that Git masterass as well. So, if you're already enrolled, you can watch it there, too. Anyway, what is a Git Workree? Well, a work tree in the simplest sense is just a working directory. It's a folder on your computer that contains a checked out version of your project. So when we clone a GitHub repo onto a computer, Git brings down the repository itself and that's the dotgit folder that contains all the repo data like commits, branches, and the full project history. And at the same time, it also creates a default work tree, which is the project files that are checked out. Usually the latest commits on the default branch, the main branch. That's most of the time. So all of that checked out project code that you see after a clone that is a git work tree. Right? Now what happens if we're working on a new feature? Well, normally we would switch to a new feature branch and start working on that new feature. Right? So imagine we're doing that and then at some point for whatever reason we need to quickly switch to another new branch. Now it could be for a hot fix or another feature we need to implement or whatever else. But we've got a bunch of code changes on this current branch that aren't ready to be committed yet. So what would we do? Well, we would normally commit those changes anyway, but that would give us a messy commit history or we could stash those changes, but stashes are a little fragile themselves, easy to forget, and you can sometimes drop or lose track or pop the wrong one and so on. So the third option then is to add a new work tree for the project. And by using multiple work trees, we don't have to then switch branches inside the same working directory anymore. Instead, we can have multiple working directories or work trees all linked to the same repository. And while one work tree could have a feature branch checked out, another work tree could have a hot fix branch checked out at the same time. And that means when we have to switch focus, we don't need to start making all those messy commits or stashing the changes. We can just add a new work tree, check out a new branch inside that work tree at the same time, and work on whatever it might be that needed your focus. Now, when we're done, we can just head back to the default work tree and carry on with the original work that we were doing. So, then we know now that a work tree is just a working directory that contains a checked out version of a project, right? And each work tree is tied to its own branch which can include uncommitted changes. But each work tree still shares the same git history, the same commits, the same remotes, and so on. So, we're not cloning the repo multiple times. We're just kind of asking it to give us different views of the same project using the same instance of the repository. And the benefit of that over multiple clones is that we're not duplicating the history. We're not storing the repo several times on the computer. And also because we just have a single repo to manage a single fetch from any work tree updates everything. Whereas with multiple clones, you'd have to update every clone separately. And also one more thing, when you use work trees, git stops you from checking out the same branch twice within those different work trees. Whereas if you've got multiple clones, there's nothing stopping you from working on the same branch in each one of those and just potentially messing up your work. So then in this series, I'm going to be working with this repo right here, which I've already added to GitHub. And I'll leave a link to this repo down below the video as well, so you can access it. But it's nothing special. It's literally just got a few HTML files inside it, CSS file and a reb. Now, I've kept this simple because I can more easily then demonstrate how work trees work. And I'm sure you're going to be working on much bigger, much more complex projects. But everything you learn using this one is essentially going to carry over to whatever project you might be working on. So then the first thing we need to do is clone this repo to our computer so we can work on it locally. And we can do that using one of these options right here. I'm just going to use HTTPS by copying this URL. Also, I'm going to be using a terminal called Warp in this series, which you can get for free at warp.dev. And the reason I'm using this terminal is because it's going to let me do two things. First, it comes with a built-in editor, so I can easily make simple code changes myself and view those changes. And second, because it also comes in with some built-in AI tools, which is going to make it easier for me to demonstrate if I need to work trees within an agentic workflow. I might use Claude, I don't know. Now, you don't have to use this terminal. You can choose whichever one you prefer. And this is not an endorsement of Walt by any means. I'm just choosing to use it for this course. So then I've opened up a new terminal and I've already cded into a project directory which you can see right here. And now I want to clone that repository by typing git clone followed by the URL I just copied and then hit enter. Now when I do that it's going to pull down that repo into a new folder called portfolio workre which we should be able to see if we run the ls command. So then let's CD into that new directory now by typing cd portfolio work trees and hitting enter. And when we do that you can see right here we automatically have the main branch checked out. Now when we run the ls command again we're going to see all the project files that git brought down for us right and these files in this folder represent the default work tree that git creates when we clone a repo. And remember a work tree is just a working directory that contains a checked out version of a project which is this. Right now if we run the ls command again this time with the a flag to see all the hidden files then we're going to see the do.getit folder and this is the repo itself where all the commit history branches refs and logs lives. So we have two things right like we said before the default work tree which is the checked out version of the project or the main branch and the git repository itself the do.git folder. Okay, so now let's imagine we want to start working on a new feature. Well, the first thing we normally do is switch to a new branch. So let's do that by typing git switch followed by the C flag to create a new branch. And we'll call this feature hyphen A. And then what we do is just start working on this feature. So I'm just going to list the contents of this project again so that I can click on one of the HTML files. And when I do that, Warp is going to let me open that file up by clicking on the open in Warp link. And then I'm just going to make any old change for now. Doesn't matter what. I'm going to save the file and then close the file, which you can do by hitting command plus W. So now we've got some code changes on this branch, but we've not finished the feature or even reached any kind of milestone, right? But then for whatever reason, we might need to switch branches to quickly work on something else like a different feature or a hot fix. So at this point, we'd either have to stash these changes now or make a commit, which we really don't want to do just yet. and then we could switch to another branch to work on that hot fix or whatever else it was. Or the other option is to add a new work tree to this repo which lets us work on a new branch in a completely separate working directory without having to stash or commit anything here. So we can leave the changes untouched. So, we're going to see how to do that in the next lesson.