Working Directory vs. Repository Root: What Changes With Git Worktrees?

If you open a project folder and start editing files, you are usually looking at both a Git working directory and a repository root. That makes the terms seem interchangeable—until you create another worktree and discover that one repository can have several project folders.

The distinction is simple: one term describes the files you work on; the other describes the top-level folder containing those files. Git worktrees make that distinction especially useful.

The Basic Difference: Files vs. Their Top-Level Folder

A working directory, also called a working tree in Git, is the set of checked-out project files you can open, edit, build, and test.

The repository root, in everyday Git usage, is the top-level folder of that working tree.

For example:

project/
├── .git/
├── README.md
├── src/
│   └── app.py
└── tests/
    └── test_app.py

Here:

• project/ is the repository root.
• The checked-out files under project/ form the working tree.
• .git/ holds Git’s internal information, rather than the project files you normally edit.

So the same folder can reasonably be called your “working directory” and your “repository root.” The terms simply emphasize different things.

The working tree is your editable checkout. The repository root is the top-level folder of that checkout.

Think of a working tree as the contents of a desk, and its root as the desk that contains them. In casual speech, you might use “my desk” to mean either the furniture or everything you are working on there. The distinction matters when you have several desks.

One More Meaning of “Working Directory”

Before introducing worktrees, it helps to separate Git terminology from a common terminal term.

Your current working directory is the folder your terminal—or a running program—is currently using. It does not have to be the repository root.

For example:

cd project/src

Your terminal’s current working directory is now project/src/, but the repository root is still project/. The Git working tree still includes the whole checkout, not just src/.

Many Git commands work from subfolders because Git can locate the checkout’s metadata. You do not always have to run them at the root.

However, telling a tool or coding agent to start at the root is often clearer: it gives the tool an unambiguous base folder for file paths and project commands.

Worktrees Give One Repository Several Checkouts

A Git worktree lets you create another checkout attached to an existing repository. Instead of repeatedly switching one folder between branches, you can keep separate sets of project files available at the same time.

A branch is a named line of development. Separate worktrees can have different branches checked out, letting you work on different tasks side by side.

For example:

workspace/
├── project/
├── project-auth/
└── project-search/

These are three sibling folders—not one project with two task subfolders.

Each contains a checkout of the project:

• project/ is the main working tree.
• project-auth/ is another working tree, perhaps for authentication changes.
• project-search/ is another working tree, perhaps for search changes.

Each also has its own root. If you are working in project-auth/, then project-auth/ is the repository root for that checkout.

This is the key shift:

With worktrees, “the repository root” identifies the root of a particular checkout—not a single folder that all worktrees must live inside.

What Is Separate, and What Is Shared?

Worktrees separate the day-to-day editing environment while sharing the underlying repository.

Each worktree has its own working state

Each worktree has its own:

• Checked-out files: the files you edit.
• Staging area, also called the index: the selection of changes prepared for your next commit.
• HEAD: Git’s reference to the current checkout position, usually the branch you are working on.

A commit is a recorded snapshot of project changes.

This separation means edits and staged changes in project-auth/ do not automatically appear as edits and staged changes in project-search/.

The repository data is shared

The worktrees share Git’s underlying repository data, including commit history and branch references.

They are therefore not independent repositories in the way two separate clones would be. They are separate working environments attached to the same repository.

That is why worktrees are useful for parallel tasks: you get separate places to edit without needing a separate repository for every task.

Why .git May Be a File Instead of a Folder

In a typical main checkout, .git is a directory containing Git metadata.

In a linked worktree—an additional checkout created with Git’s worktree feature—.git is typically a small file pointing to metadata stored under the main checkout’s .git directory.

Conceptually:

project/
└── .git/              Git metadata directory

project-auth/
└── .git               File pointing to worktree metadata

project-search/
└── .git               File pointing to worktree metadata

The linked worktree still has a repository root and a complete set of checked-out project files. Its .git file simply tells Git where to find the information needed to manage that checkout.

A .git file does not make the folder any less of a working tree.

What to Tell a Parallel Agent

If you assign an agent to the authentication task, a clear instruction is:

Work in workspace/project-auth/. Treat that folder as the root for file edits and project commands.

That instruction selects the agent’s checkout. It does not tell the agent to work inside a subfolder of project/, nor does it direct the agent to Git’s internal metadata.

The practical rule is straightforward: give each parallel task its own worktree, and make clear which worktree root it should use. The folders provide separate editing spaces; Git connects them to the shared repository behind the scenes.