Git Worktrees Tutorial #4 - Worktree- First Approach

Net Ninja| 00:07:56|Mar 11, 2026

Chapters9

Create separate work trees adjacent to the .git folder to isolate work on new features or fixes.

Net Ninja walks you through setting up Git worktrees to manage branches like main, feature, and hotfix without stashing.

Summary

Net Ninja explains how to work with a bare Git repository by adding adjacent work trees inside the same project folder. He starts by creating a main work tree for reference, using git worktree add dot/main on the current branch. Next, he creates a feature work tree (feature ABC) by using the -b flag to check out a new branch, demonstrating how each work tree corresponds to its own checked-out branch. He shows switching into each work tree and making a small change to verify there’s an uncommitted modification, then viewing status with git status. To illustrate rapid shifts, he creates a hotfix work tree (hotfix123), makes a change, commits, and pushes the branch to the remote, followed by merging the pull request on GitHub. Net Ninja also demonstrates removing a finished work tree with git worktree remove and updating the main work tree to reflect merged changes with git fetch or git pull. The overall approach keeps all work trees together in a single project directory, reducing the clutter of stash or scattered commits. He closes by noting that work trees are especially useful for concurrent development scenarios and hints at their rising popularity in AI-related workflows.

Key Takeaways

git worktree add . /main creates a dedicated work tree for the current branch, stored under a separate main folder.
Creating a new feature work tree uses git worktree add with -b feature-ABC and a path like /feature-ABC to auto-checkout the feature branch.
A hotfix work tree (e.g., hotfix123) can be created in parallel by specifying -b hotfix123 and a matching folder path, enabling immediate work on the fix.
Switching into a work tree automatically checks out the corresponding branch, allowing direct file edits without stash or interim commits.
After finishing, you can push the feature or hotfix branch and merge via a pull request, then remove the local work tree with git worktree remove dot/sl-hotfix-123.
To stay up to date after merges, you can update the main work tree with git pull or run a fetch in the parent to refresh refs.

Who Is This For?

Essential viewing for developers who want to manage multiple Git branches in parallel without frequent stashing or messy commits. Great for teams adopting worktrees to keep main, features, and hotfix work in sync within a single project directory.

Notable Quotes

"The way we're going to approach this then is by creating work trees within the project folder adjacent to the do.git folder."

—Introductory setup concept for organizing work trees beside the bare repository.

"If I wanted to work on a new feature, I could make a new work tree called feature ABC or whatever the feature was called."

—Demonstrating naming and creating a feature-specific work tree.

"And all I'd be doing then is switching between these different directories to work on different branches when I needed to."

—Core benefit: isolation of work by directory/branch without stashing.

"Then I’m going to make a new work tree now by typing git work tree add followed by the B flag to switch to a different branch new one which I’m going to call hotfix123."

—Practical step for starting a hotfix work tree with a new branch.

Questions This Video Answers

How do Git worktrees help avoid stash churn in multi-branch development?
What is the exact syntax for adding a work tree with a new branch using git worktree add -b?
Can I manage multiple work trees in one repository and how to remove a finished work tree?
What are best practices for keeping a main work tree up to date after merging branches?
When should I consider using worktrees rather than traditional branching strategies?

GitGit Worktreesgit worktree addGit branchingFeature branchesHotfix workflowPull requestsNet Ninja

Full Transcript

Okay, so in the previous lesson, we cloned a bare repository to our computer and we put that inside a do.git folder within a project directory called portfolio, which is where I am now. So if we run the ls command with the a flag to list the contents, then we should see that git folder. And when we cloned this bear repo, git didn't create a default work tree for us. So there's no project code here yet. And what I want to do now then is make some work trees so I can start working on new features or bugs or whatever else. The way we're going to approach this then is by creating work trees within the project folder adjacent to the do.git folder. Now the first work tree that I might make is one for the main branch as a reference. A bit like having a default work tree but in its own folder called main. And I probably wouldn't ever use that work tree or branch for working directly in the code. But I could use it to pull the most recent version of main down occasionally and view the code in its current state. Then if I wanted to work on a new feature, I could make a new work tree called feature ABC or whatever the feature was called. And inside that work tree, we'd have a new branch checked out for that feature. If I wanted to switch focus and start working on a bug, I could just create another work tree called bug XY Z and check out a new branch inside the work tree to work on it. And all I'd be doing then is switching between these different directories to work on different branches when I needed to. Won't need to stash. I won't need to make any commits. I don't want to. Then once I've pushed and merged a branch into main on GitHub, I could pull down that latest version of main into this main work tree to keep everything up to date. And the reason I like this approach personally is because we're keeping all the work trees, the bear repo together inside a single project directory. So I feel like it's more organized this way to easier manage all the different work trees. But anyway, let's try doing something like this in our project folder. So then I'm already in the portfolio project folder and within this all we have is the do.git git folder for the bear repo for now. And now I want to make a new work tree for the main branch first of all just so we have the main work tree as a reference and we can use it when we need it. To do that then we can type get work tree add. And since we're already on the main branch we don't need to specify a new branch to check out or anything. We just need a directory path for the workree which is going to be inside a folder called main within this current directory. So we can just say dot/main to do that. and then hit enter. All right, so that's going to create a new work tree for us. And if we run the ls command now, we should see that new main directory. If we cd into that directory, we can run ls again. And then we should see all the project files. Okay, so like I said, I don't typically work inside this work tree and I mainly use it to pull down the latest version of main and use it for reference. But now then I want to cd back into the parent project directory and make a new work tree to work on maybe a feature or something. So let's do that. And we're going to type the command get workree add. And this time we do need the B flag to check out a new branch for this work tree. And I'm going to call that feature ABC. Doesn't really matter what it's called. After that we need the path to the work tree which is going to be slashfeature ABC. the same name as the branch and then we can just hit enter. Okay, so now if we run ls, we should see both a main folder and the feature ABC folder, one for each work tree. And if we cd into the feature hyphen ABC workree, we should see that we get switched to the feature ABC branch. So I could just start working on this feature now inside this work tree. So let me run the ls command and then open up an HTML file. It doesn't really matter which one. Then make a change and then save it. So that now we've got an uncommitted change on the branch. And if we run the get status command, we should see the uncommitted change. All right. So now let's imagine we need to quickly switch to another branch for a hot fix or something. So what I would do now then is probably CD out of this feature workree back into the parent project folder and then create a new work tree from here. Now I don't technically need to CD out of that directory that I was in. I could have made the new work tree directly from that feature work tree, but this is just something I do to avoid adding the new work tree where I shouldn't or using the head location within that work tree to base the new branch on just in case I had extra commits on that feature one. And again, you can specify which branch to use as a base for the new work tree, but I just find this approach easier. So then I'm going to make a new work tree now by typing get work tree add followed by the B flag to switch to a different branch new one which I'm going to call hotfix123 or something and then we need the path for that new work tree which is going to be the same name as the branch so forward slashh hotfix123. All right. So now once we've done that and we run the ls command, we should see that new folder. Also we could run the get workree list command right now as well. And when we do that, we should see three different work trees we added. One for the main, feature one, and now the hot fix one. Anyway, let's cd into the hot fix 123 directory now. And when we do that, we should automatically get switched to the hot fix branch as well. Okay. So now we can make some kind of change in this work tree. So, let me list out the contents first of all so we can see the files and then I'm just going to open up the readme file right here and make a quick change to that file. Doesn't really matter what and then we can save the file. So, after that, we might want to make a commit and push this hot fix branch up for merging into main. So, let me just quickly do that by typing git commit. And then we're going to use the A flag to add the change to staging plus the M flag for a commit message which can just be something like update readme. All right. And then we can hit enter to make that commit. Now after that we can push the branch up by typing git push origin and then hotfix123 which was the branch name and then we can hit enter. All right. And on the repo we can see that new branch has been pushed up. We can make a pull request by coming down here. Add a description if you want. I'm going to create the pull request. And then we can merge once these checks are done. Let's merge it right here. Confirm the merge. And then we could also delete the branch from the remote repo as well. Okay then. So now we've worked on that hot fix. We've made a commit, pushed the branch up and merged it into main. So we could now delete this local hotfix work tree by coming back into the parent directory. first of all and then using the command get work tree remove followed by the path of the work tree that we want to delete which is just dot slhotfix-123. After that I might also want to update this repo to incorporate that newly updated main branch which I could do in a couple of ways. We could run a git fetch right here, or we could cd into the main work tree, which is what I'm going to do, and run a git pull, which is going to pull down that updated main branch right here, and also update the git repo with all the remote refs and whatnot. And if I wanted to now, I could just go ahead and carry on working on whatever feature I was working on before. So then, that's an example workflow that I might use when I'm working with work trees. And for me, if I'm needing to work on multiple branches at once, I find it much easier this way using work trees than constantly stashing changes or making commits that I don't really want to make. Anyway, hopefully you can see now how helpful work trees can be in a standard development workflow. And in the next lesson, I'm going to explain why they're being used quite frequently now in AI workflows as