Most engineers use Git daily. Few people use this feature
Constantly switching branches, storing unfinished work, and losing context seemed normal until I discovered a Git feature that solved all three.
Think with me:
You are working on a new feature. Halfway through implementation, a production issue arises in Microsoft Teams.
- You hide your changes.
- Change branch.
- Fix the problem.
- Push the fix.
- Go back.
- Apply the stash.
- Resolve conflicts.
- Keep working.
A few hours later, QA reported another bug.
And you repeat the whole process again.
For many developers, this workflow seems completely normal.
We’ve been doing this for years. But after a while, I started to wonder:
Why do I spend so much time managing branches instead of writing code?
This question ultimately led me to Git Worktrees.
And honestly, I wish I had learned them a lot sooner.
The problem that no one talks about
Let’s imagine a common scenario.
You are working on a frontend application.
You have three parallel tasks:
- Feature: New dashboard
- Feature: user notifications
- Bug fix: connection redirection issue
Using traditional Git workflows, you typically do this:
git checkout feature-dashboard
Work for a while.
SO:
git checkout bugfix-login
SO:
git checkout feature-notifications
Each switch means:
- Waiting for files to change
- Losing context
- Manage reserves
- Accidental clerks on the wrong branch
The bigger the project gets, the more boring it becomes.
What if each branch could have its own directory?
What if you could keep multiple branches open simultaneously?
This is exactly what Git working trees solve.
What exactly is a Git Worktrees?
A Git working tree allows multiple working directories to share the same repository history.
Think about it like this.
Instead of:
project/
You can have:
project-main/
project-feature-a/
project-feature-b/
Each directory points to a different branch.
All share the same Git repository internally.
This means:
- No additional clones required
- Less disk usage
- Multiple branches active simultaneously
It’s like having multiple checkouts of the same repository without cloning it multiple times.
My first experience
I created a simple repository containing:
index.html
README.md
styles.css
Initially:
git branch
showed:
main
I created my first feature branch:
git switch -c feat-a
Then modified:
index.html
Then I created a working tree.
git worktree add -b feat-b ../feat-b
Git instantly created the following:
project(main)/
feat-b/
Now I had two directories.
project(main) -> feat-a
feat-b -> feat-b
That’s when the concept finally made sense to me.
Each branch now has its own workspace.
- No cash register.
- No hiding place.
- No change of branch.
The confusing part that fooled me
Everything looked perfect.
Until I checked the Git status.
I changed :
README.md
inside the second working tree.
Then I returned to the first working tree and executed the following:
git status
To my surprise, Git showed:
modified: index.html
modified: README.md
Wait…
- Why was the first working tree showing the changes compared to the second working tree?
- Have I misunderstood how worktrees work?
- Was Git broken?
For a few minutes, I genuinely thought that the working trees were sharing uncommitted changes.
But that’s not the case.
The actual problem was much simpler.
The real problem was VS Code
After some debugging I found that Git behaved perfectly.
VS Code was not.
I had initially opened the following:
project/
inside VS Code.
Later I created:
../feat-b
using Git Worktree.
The problem was that VS Code always worked in the first folder.
I thought I was editing:
feat-b/README.md
But I was editing:
project/README.md
Git simply reported what happened.
The changes never happened in the second working tree.
They happened in the first one.
The moment I opened the second working tree in a separate VS Code window, everything started working exactly as expected.
To remember: Git Worktrees does not share uncommitted changes. If you see behavior that suggests otherwise, check your editor and workspace configuration.
The mental model that made everything clear
Think of a Git Worktree as a completely separate working directory.
feat-a/
And
feat-b/
are independent workspaces.
Each workspace has:
- His own files
- His own uncommitted changes
- Your own branch cash register
But they share:
- Validation history
- Objects
- Repository data
This is why working trees are lightweight compared to repeated cloning repositories.
How to use Git Worktrees in real projects
Imagine you are working on the following:
feature-payment
feature-notifications
bugfix-login
Instead of constantly changing branches:
git checkout
you can create:
git worktree add ../feature-payment feature-payment
git worktree add ../feature-notifications feature-notifications
git worktree add ../bugfix-login bugfix-login
Now open each one separately.
VS Code Window 1 ->Payment
VS Code Window 2 ->Notifications
VS Code Window 3 ->Bug Fix
- Each task remains isolated.
- Each branch maintains its own context.
- No hiding place.
- No accidental branch switching.
- No loss of momentum.
Commands you’ll actually use
Create a work tree:
git worktree add ../feature-x feature-x <from which branch>
Create and switch to a new branch:
git worktree add -b feature-x ../feature-x <from which branch>
Show all work trees:
git worktree list
Delete a work tree:
git worktree remove ../feature-x
Final Thoughts
Most developers are familiar with branches.
Far fewer know about Git working trees.
Yet, work trees solve one of the most common frustrations in software development: juggling multiple tasks at the same time.
The biggest lesson from my learning experience wasn’t actually about Git.
It was about tools.
Git working trees were working fine from the start.
My editor wasn’t operating where I thought he was.
Once I understood this distinction, the whole concept became incredibly simple.
If you keep juggling caches, switching branches multiple times a day, or losing context between tasks, spend an hour learning Git Worktrees. This may be one of the most effective Git features you’ll ever use.
And it’s over! If you made it this far, I hope you found something useful.
If Git Worktrees has ever saved you from the cache-switch-conflict cycle, applaud this article and share it with your team or other developers who might also benefit from it.
And if you have your own workflow or work tree tips, I’d love to hear them in the comments.
Join me for my real stories. Real engineering here
Until next time keep building, stay curious, and write code that makes a difference.
https://www.linkedin.com/in/karthiks05/
More useful reading (worth your time):
1. How we built a robust message queue using BullMQ
2. Docker has changed. Most engineers haven’t done it
3. Beyond Microservices: Scaling and Decoupling with a Hybrid NestJS Architecture
4. Creating a Health Check REST API in a NestJS standalone application (without listening on any ports)
Most engineers use Git daily. Few Users Use This Feature was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.
PakarPBN
A Private Blog Network (PBN) is a collection of websites that are controlled by a single individual or organization and used primarily to build backlinks to a “money site” in order to influence its ranking in search engines such as Google. The core idea behind a PBN is based on the importance of backlinks in Google’s ranking algorithm. Since Google views backlinks as signals of authority and trust, some website owners attempt to artificially create these signals through a controlled network of sites.
In a typical PBN setup, the owner acquires expired or aged domains that already have existing authority, backlinks, and history. These domains are rebuilt with new content and hosted separately, often using different IP addresses, hosting providers, themes, and ownership details to make them appear unrelated. Within the content published on these sites, links are strategically placed that point to the main website the owner wants to rank higher. By doing this, the owner attempts to pass link equity (also known as “link juice”) from the PBN sites to the target website.
The purpose of a PBN is to give the impression that the target website is naturally earning links from multiple independent sources. If done effectively, this can temporarily improve keyword rankings, increase organic visibility, and drive more traffic from search results.
