Review Pull Requests with Git Worktree

Imagine I am in the middle of a task. I have changed a few files, the code is not ready, and then someone asks me to review a pull request.

Normally, I might commit unfinished work, stash my changes, or clone the repository again just so I can check out the pull request branch. None of those options feels ideal. I do not want a temporary commit in the history, I do not want to remember what I put in a stash, and I do not need another full clone.

This is a great use case for Git worktree.

The workflow

The idea is simple: instead of interrupting my current directory, I create a second one for the review. Both directories share the same Git repository, but each one keeps its own checked-out branch and working files.

The important part is that creating or removing the review worktree does not change the files in my original directory.

What is a Git worktree?

A worktree is another working directory connected to the same Git repository. Each worktree can have a different branch checked out, while sharing the repository history and configuration.

That means I can keep my current directory exactly as it is, including all my uncommitted changes, and open the pull request branch in another directory.

My directories might look like this:

1projects/
2├── my-project/            # My current task
3└── my-project-pr-review/  # The pull request

Create a worktree for the pull request

First, I fetch the latest remote branches:

1git fetch origin

Then, from my existing repository, I create a worktree for the pull request branch:

1git worktree add ../my-project-pr-review --track -b feature-branch origin/feature-branch

This command:

• creates the ../my-project-pr-review directory;
• creates a local feature-branch that tracks origin/feature-branch; and
• checks out that branch in the new directory.

I can now move into it and start the review:

1cd ../my-project-pr-review

I can install dependencies, run the application, execute tests, and inspect the changes without touching the work in my original directory.

If I only need to review the code and do not plan to commit anything, I can create a detached worktree instead:

1git worktree add --detach ../my-project-pr-review origin/feature-branch

Making changes in the worktree

A worktree is not a disposable copy with a separate Git history. It is part of the same repository, so Git works as usual inside it.

If I make a change while reviewing the pull request, I can create a commit:

1git add .
2git commit -m "Fix validation edge case"

That commit belongs to the branch checked out in this worktree. Because feature-branch tracks the remote branch, I can push it in the normal way:

1git push

The commit is then sent to origin/feature-branch, the branch used by the pull request. This assumes I have permission to push to that branch. For a pull request opened from someone else's fork, I would usually leave review comments or push to a branch I own instead.

My unfinished changes in the original worktree are still there and remain completely untouched.

Working on parallel tasks

The same workflow is useful for more than pull request reviews. I can use a worktree when I need to fix an urgent bug, compare two branches, or work on two tasks in parallel.

For example:

1git worktree add ../my-project-hotfix -b hotfix/login-error main

Now I can work on the hotfix in one directory and continue my original task in the other. Each directory has its own files and checked-out branch, but commits and branches are available to the whole repository.

One detail to remember: Git does not allow the same branch to be checked out in two worktrees at the same time. In practice, that is helpful because it prevents me from changing the same branch from two different directories by accident.

See and remove worktrees

To see all worktrees connected to the repository, I run:

1git worktree list

When the review or parallel task is finished, I return to my original repository and remove the extra worktree:

1git worktree remove ../my-project-pr-review

Git will refuse to remove it if it contains uncommitted changes. I can then delete a local branch I no longer need:

1git branch -d feature-branch

Conclusion

Git worktree gives me a clean way to change context without disturbing work that is already in progress. I do not need a temporary commit, I do not need to stash anything, and I do not need to clone the whole repository again.

The original task stays open in one directory, the pull request or parallel task lives in another, and commits still go to the branch checked out in each worktree. It is a small Git feature that makes interruptions much easier to handle.