Git Worktrees: Keep Two Branches Open in Separate Folders

You want to compare two branches, keep a review open or fix a bug while another task remains half finished. A linked Git worktree gives the second branch its own folder. Your original files and staging area can stay where they are while you work in the new directory.

Use git worktree when you need both checkouts available at once. Each has its own files, staging area and checked-out position, but they belong to one repository. Shared history makes this convenient; shared configuration and external services still need care.

This guide covers an ordinary repository without submodules, using commands documented before 11 February 2026. The worked example was checked in a disposable repository with Git 2.39.5; the linked references use Git 2.48.0 documentation, released in January 2025.

Create a second folder from an explicit base

Suppose your current checkout is project on feature/menu. It contains staged edits, more unstaged changes and a new notes file. You want a separate bug-fix/login-timeout branch starting from the team's shared base.

From project, inspect the current state and existing worktrees:

git status --short --branch
git worktree list

The first command names the branch and lists local changes. The second maps checkout paths to branches. Keep the original status output so you can compare it afterwards. Git's status reference documents the short listing and branch option.

Refresh the remote references:

git fetch origin

Here, origin is the example remote and origin/main is the intended base. Substitute your project's actual names, such as origin/edge. Stop if fetching fails. Fetching updates remote-tracking references ; it does not mean you have switched your current checkout to that branch.

Create the second checkout with this single command:

git worktree add --no-track -b bug-fix/login-timeout ../project-login-fix origin/main

The three important choices are the new branch name, the new folder and the starting commit. ../project-login-fix is a sibling of project, so the second checkout sits outside the original working directory. Choose an unused path and branch name.

Lowercase -b creates the branch and refuses to replace an existing one. --no-track leaves the new branch without an upstream, rather than automatically tracking the base branch. The worktree options and branch tracking reference describe these choices. Share the eventual fix through your team's normal branch and review workflow. If integrating it produces a conflict, use our guide to resolving a Git merge conflict .

Check both directories before editing

Still in project, inspect the new checkout without changing directories:

git -C ../project-login-fix status --short --branch
git status --short --branch

The first status should name bug-fix/login-timeout with no changed paths. The second should still show your original branch and unfinished work. In our disposable example, the staged file version, additional unstaged edits and untracked notes all remained in the original folder. The new folder contained the committed base version instead.

Open project-login-fix in a separate editor window. Check its branch before making a commit, and run commands from that window's terminal. Similar-looking windows are an easy way to edit the wrong checkout.

Local setup does not automatically follow you. Our example included an ignored .env file in the original checkout; it was absent from the new one, as was the untracked notes file. Follow the project's setup instructions for dependencies, local configuration and generated assets. Copy only configuration appropriate to the new task, keeping secrets out of commits.

Know which resources are still shared

A linked checkout uses a .git file pointing to repository metadata elsewhere. It shares the object store and ordinary branch references with the repository that created it. The repository layout reference explains that arrangement. Keep the original repository in place while its linked worktrees depend on it; the second folder is not an independent backup.

Repository configuration is shared by default, too. Changing a remote URL in one checkout can affect the others. The worktree configuration section documents this default. For this workflow, leave shared settings alone unless you intend a repository-wide change.

Separate source folders also do not allocate separate ports, databases or cloud resources. For example, if both copies of a web app try to listen on port 3000, choose another port for one. Check database and service settings before running migrations or background jobs. These are application setup decisions beyond Git's checkout separation.

If the branch is already checked out

Git normally refuses to check out the same branch in another worktree. That refusal occurred in our example when we requested feature/menu, which was still open in the original folder. Use git worktree list to find the checkout instead of overriding the protection.

If a local branch already exists and is available, omit -b:

git worktree add ../project-login-fix bug-fix/login-timeout

Use this as an alternative to creating a new branch, or to reopen it after removing its earlier checkout. Do not substitute uppercase -B to get past an existing-name error: Git documents that it can reset the branch to the supplied starting point.

Remove the folder after preserving its work

Finish the fix, review and commit the changes you need, and use the project's sharing process. Then return to the original project directory. Stop processes using the linked folder and inspect everything local to it:

git -C ../project-login-fix status --short --ignored

The --ignored option exposes ignored paths as well as ordinary changes. Review any !! entries for configuration or data you want to retain; move needed local files to a safe location before removing the folder. A clean ordinary status is not an inventory of ignored files.

When the checkout is ready to discard:

git worktree remove ../project-login-fix
git worktree list

In our example, an untracked scratch file blocked removal and remained intact. After preserving the work and leaving a clean checkout, removal succeeded. The branch still pointed to the fix commit, and adding that existing branch again restored the committed files. The worktree removal reference describes its clean-worktree requirement. If removal refuses, inspect the reason rather than adding --force.

The final list should show that the linked folder is gone. Run git status --short --branch in the original checkout once more: your first task should still be on its original branch, ready to resume.