Are GIT Worktrees just a copied folder?

No, it's not just a copied folder — and that difference matters more than you'd think

Picture this: you're deep in the middle of a feature branch, files half-changed, tests broken on purpose, the kind of messy state you don't want to touch. Then your lead drops a message — "hey, can you quickly check that bug on main?" You know the feeling. You either stash everything and hope you remember where you were, or you clone the whole repo again into another folder and feel slightly guilty about it. There's a third option most developers never hear about: Git worktrees. And once you understand what they actually are, you'll wonder why nobody told you sooner.

What a worktree actually is (and what it isn't)

A Git worktree is not a copy of your repository. That's the first thing to get straight. When you duplicate a folder manually — drag, drop, rename to my-project-copy — you're creating a completely separate, disconnected thing. It has its own .git folder, its own history, its own everything. Changes in one don't talk to the other unless you manually push and pull. It's like having two different notebooks instead of two bookmarks in the same one.

A worktree is more like opening a second window into the same book. Your repository stays one single repository — one .git folder, one history, one set of branches — but Git lets you check out a different branch into a completely separate folder on your machine, at the same time. Both folders are live. Both are connected to the same underlying repo. You can be working on feature/checkout-flow in one terminal and hotfix/payment-crash in another, simultaneously, with no stashing, no context-switching mess, no second clone.

The command to create one is straightforward:

git worktree add ../my-project-hotfix hotfix/payment-crash

That creates a new folder called my-project-hotfix next to your main project folder, with the hotfix/payment-crash branch checked out and ready to go. You open it in your editor, make your fix, commit, push. Then you close it, and your main folder is exactly where you left it — no stash, no drama.

When does it actually make sense to use one?

Worktrees shine in a few specific situations. The first is the one described above: you're mid-work and need to switch context fast without losing your flow. Instead of stashing — which always feels like putting your desk in a box and hoping you packed everything — you just spin up a worktree for the urgent thing and keep going.

The second situation is running things in parallel. Say you're doing a code review and want to actually run the other person's branch locally while you keep working on yours. With worktrees, both branches are running simultaneously. No checkout back and forth, no "wait, which version am I looking at right now?"

The third, and increasingly important situation, is working with AI coding agents. This is where things get genuinely interesting.

Why worktrees matter a lot in the age of AI agents

If you've started using tools like Claude, Cursor, or any AI coding agent that can autonomously write and modify files, you've probably run into a weird new problem: the agent wants to work in your repo, but you also want to keep working in your repo. Two workers, one workspace. It gets messy fast.

Worktrees solve this cleanly. You create a dedicated worktree for the agent to operate in — its own folder, its own branch — while you keep your main working directory untouched. The agent can read, write, run commands, make commits, all inside its own space. You review what it did, merge if it looks good, and move on. No risk of the agent overwriting something you were halfway through. No mysterious file changes you didn't ask for appearing in your current branch.

As more teams start running multiple agents in parallel — one tackling a bug, another drafting tests, another refactoring a module — worktrees stop being a nice-to-have and start being the only sane way to organize that kind of work. Each agent gets its own worktree, its own branch, its own sandbox. The repository stays clean and unified underneath it all.

Should you use worktrees by default, for everything? Probably not. For simple solo work on a single task, your regular checkout is fine and adds less overhead. But the moment you're juggling more than one thing — or the moment an agent enters your workflow — worktrees are the right tool. They're not an advanced Git trick for power users. They're a practical solution to a problem that every developer has faced, and that's only becoming more common.

A small tool, a real shift in how you work

Git worktrees won't change your life overnight. But they'll quietly remove a whole category of friction that you've probably just accepted as normal — the stashing, the second clones, the "wait which branch am I on" moments. And in a workflow that increasingly involves AI agents doing work alongside you, having clean, isolated spaces for each thread of work isn't optional anymore. It's just good practice.

If you're a developer trying to figure out how to build smarter, calmer workflows in this new era of AI-assisted coding, small tools like this are worth understanding deeply. At Esquyna, we think a lot about how professionals can work better with the tools they already have — and sometimes the best insight is just knowing that a better option exists.