Use Git Worktrees to Review a Patch Without Losing Your Place

You are halfway through a change when a teammate asks for a review. Stashing everything can work, but it interrupts your context and may include files you did not intend to move. A linked worktree gives the same repository another working directory with its own checked-out files and index.

Create a detached review directory

Fetch the review reference through your normal trusted remote workflow. From the original repository, run git worktree add --detach ../review-copy <commit>, replacing the placeholder with the reviewed commit ID. A detached checkout is convenient for inspection. If you intend to keep edits, create a named branch in the review directory before committing.

Run git worktree list to confirm which directory holds which revision. Your original uncommitted edits stay in the original directory. Git generally prevents checking out the same branch in two worktrees at once; use a detached revision or another branch instead of forcing it.

Isolate what Git does not manage

Worktrees share repository objects and references. They do not automatically isolate dependency caches, database connections, environment variables, ports or background jobs. A second checkout pointed at the same development database can still change the first checkout's data.

Set a distinct test database and port when needed. Install or build dependencies in the review directory according to the project. Run the failing test or start the review server there, then record the commit ID alongside the result.

Finish without dropping work

Check git status inside the review directory. Commit or otherwise preserve anything worth keeping. From another worktree, run git worktree remove ../review-copy when it is clean. Avoid forcing removal to silence a warning; that warning may be the last reminder that an experiment exists only in that directory.

Further reading

Git: worktree

Related guide: Find the First Bad Change in a Software Release.