Git Worktrees Tutorial #2 - Adding Git Worktrees

Net Ninja| 00:07:03|Mar 6, 2026

Chapters9

Introduces the idea of a work tree and why you would use it to switch branches without committing or stashing your changes.

Add and manage separate work trees with Git to work on a new branch without touching your current changes.

Summary

Net Ninja shows how to practically use Git work trees by adding a second, separate working directory for a different branch. He starts from a repo with uncommitted changes on feature A and demonstrates creating a new work tree with git worktree add -b feature-B ../feature-B, then verifies it with git worktree list. He highlights that the new work tree starts from the current HEAD unless you specify a different starting point, and walks through entering the new directory, making a change, and switching back to the original work tree. The lesson then covers removing a work tree with git worktree remove and forcing removal if there are uncommitted changes, followed by deleting the corresponding branch if desired. Finally, Net Ninja introduces the option to initialize the new work tree from a different starting branch (e.g., main) and teases the concept of bear repositories for a more work-tree-first workflow in the next video. The practical steps are illustrated with concrete commands, like cd, ls, git status, and the readme edit, making it clear how to parallelize work on multiple features without stash or commit clutter.

Key Takeaways

Use git worktree add -b <new-branch> <path> to create a separate working directory for a new branch.
The new work tree starts from the current HEAD by default unless you explicitly specify a starting point (e.g., main).
You must cd into the new work tree directory to work on that branch; Git does not auto-switch you to the new location.
You can verify work trees with git worktree list to see each directory and its checked-out branch.
Deleting a work tree with git worktree remove requires removing uncommitted changes first unless you force with --force.
After removing a work tree, the branch can still exist; you may delete it with git branch -d <branch> if you no longer need it.
You can start a new work tree from a different base branch by adding the target branch (e.g., main) to the git worktree add command.

Who Is This For?

Designed for developers who juggle multiple features in a single repo and want to avoid stashing or committing interim work. Ideal for Git users looking to simplify parallel development with dedicated work trees.

Notable Quotes

"So instead, what we can do is add a new work tree for this project and work on a different branch in that new working directory without touching the changes we already have here in this default work tree on this branch."

—Introductory rationale for using a separate work tree to avoid affecting the current working directory.

"Git is going to make that new work tree in that new folder and check out the new branch for us inside that folder."

—Shows the automatic checkout behavior when creating a new work tree.

"You can force that process by adding the force flag at the end of the command which I'm going to do now just to get rid of the work tree."

—Demonstrates forcing removal of a work tree with uncommitted changes.

"If I’d already made a commit on this branch, then the new work tree we add is created starting from that latest commit."

—Clarifies starting point for new work trees relative to current HEAD.

"Then the next lesson, we’re going to focus on what a bear repo is."

—Foreshadows bear repositories as an alternative workflow.

Questions This Video Answers

How do I create a new Git work tree and switch to a different branch without stashing?
What is the exact command to remove a Git work tree and when can I force it?
Can I start a new work tree from a different base branch like main instead of the current HEAD?
What is a bear repository and how does it relate to Git work trees?

Git worktreegit worktree addgit worktree listfeature branchesbranch managementbear repositorymultiple working directories

Full Transcript

All right. In the last lesson, we talked about what a git work tree is and why it's useful when you need to change what you're working on without committing or stashing your current changes. In this lesson, I'm going to show you how to actually use work trees by adding a new one and working on a different branch inside it. So, at the moment, we've already cloned this repo onto our computer and we started work on a new feature branch which currently has some uncommitted changes. Now imagine that for whatever reason we need to switch branches maybe for a bug fix, maybe for another feature, hot fix, whatever. So normally before we switch branches, we'd have to either stash these current changes or make a commit. And sometimes we don't really want to do either of those things yet. So instead, what we can do is add a new work tree for this project and work on a different branch in that new working directory without touching the changes we already have here in this default work tree on this branch. To do that, then we can just type the command get work tree add. And then we're going to use the B flag to say we want to create a new branch to work on in this new work tree. And then we're going to follow that with the branch name, for example, feature hyphen B. And then finally, we need a relative path to a new folder for this work tree, which I would recommend placing alongside your original cloned project directory and not inside this one. So it would start with two dots to come out of this project directory and then a forward slash and then the folder name which I generally call the same as whatever the branch is going to be. So feature hyphen B in this case. Then when we hit enter, Git is going to make that new work tree in that new folder and check out the new branch for us inside that folder. And just really quickly before we switch directories to that new work tree, we can verify the work tree was created by running the command get workree and then list. And when we do that, we should see the directories of each work tree associated with this repo along with whatever branch is currently checked out in both of them. Now, one important thing that you need to understand is that because we didn't tell git otherwise, it's going to use the current head as the starting point for this new branch. So, if I'm currently on the feature a branch in this default work tree and I've already made a commit there, then the new work tree we add is going to be created starting from that commit. And if we don't want that, we need to explicitly tell git which branch or commit to start from like main, which I will show you later on. Anyway, notice that we're still in the same project folder in the terminal, right? And we're still on the feature a branch. We're not in the new one. And that's because git doesn't automatically drop us into the new work tree directory. We have to manually do that. So, if I cd out of this current directory and then run the ls command, you should see that the new directory we just created is there now for the second work tree. And now I can cd into that folder. And when I do that, you're going to see that we're on the featureb branch within this work tree. And if I run a git status, then you'll notice there's no changes on this branch. And it says the working tree is clean. So we could go ahead and start making changes now. Adding a commit and then pushing those changes up the same way as normal. So let me just run the ls command to list the contents of this working directory. And then I'm going to click on the readme file to make a quick edit. Then I'm going to save the file. So now we've got changes on this branch in this work tree. And if we wanted to now, we could leave these changes for a while. And we could head back to the other work tree to carry on with feature A. If we wanted to to do that, I could just CD back into the default work tree by typing CD dot dot slash to come out of the directory first, then portfolio- work trees. And when we do that, we should get switched to the feature A branch, still with those changes from before, but not the one that we just added to the feature B branch. And I can demo that by quickly running git status. And we can see that it's only the HTML change inside this branch. So then imagine we've made all the changes we've needed to do in that second work tree and we've pushed the branch up and we've merged it. Well then after that we could go ahead and delete that work tree. To do that we can use the command get workree again. This time we say remove and then the path to the workree itself which in this case is dot dot slash then feature-b. Now, if I hit enter to run this command, it's not going to work because we're trying to remove a work tree with a branch checked out that has uncommitted changes. And when I press enter, you can see that. So, git protects us from deleting a work tree that contains uncommitted changes. And normally in a standard workflow, that wouldn't be the case, right? We'd most likely have made a commit before deleting it, unless it all went south and it became a failed experiment or something. So you can force that process by adding the force flag at the end of the command which I'm going to do now just to get rid of the work tree. So again we say get work tree remove followed by the path to the work tree which is do/ featureb and then we add the force flag at the end. And when I hit enter this time, git should go ahead and remove that work tree along with any uncommitted changes within it, which we can verify by running the git work tree list command again just to make sure it's gone, which it is. But the branch doesn't get deleted. It's still there, which we can check by running get branch. So if you want to delete the branch now, you could do by typing get branch then hyphen d then the branch name which is feature hyphen b and that's going to go ahead and delete it. Okay then. So we've seen now how to make a new work tree for this project and also how to delete the work tree when we're done. I also mentioned before that when we created that new work tree it used the current head as the starting point of the new branch. Right? So since I'm on the feature a branch, if I'd already made a commit on this branch, then the new work tree we add is created starting with that latest commit. Now if we don't want that, we can explicitly say to get which branch to start from and then it starts from the latest commit on that branch. We can do that by typing out the same command as before, which was get workree add. Then it would be the B flag to check out a new branch in that work tree. Then the name of the new branch we want to check out. For example, feature hyphen C. And then the path to the new work tree, which could be dot dot slash to come out of the directory, then feature C. And then finally, the branch we want to start from in this work tree like main. And if we were to run that, then git will create the new work tree starting from the latest commit on main, not from wherever we currently are. So that's the basics of work trees, and that's one way we can work with them. However, another way to organize work trees is to clone what's known as a bear repository and then use that to follow a more kind of work tree first workflow, I guess. So, in the next lesson, we're going to focus on what a bear repo is.