git review — VS Code extension

Review a pull request by editing and running it, from a panel that shows where you are in it.

This is the editor surface of git-review-workflow, a git subcommand that stages an entire PR in your working tree as staged, uncommitted changes — so you read the diff, edit it inline and run the tests like ordinary local work, and git review finish then extracts your edits onto a separate branch. The extension does not reimplement any of that: it drives the same CLI and shows you its state.

The CLI is required. The extension is a panel over git review, not a standalone reviewer. See Requirements.

What the panel shows

A reading order, when the PR has one. If the author (often an AI coding agent) committed a walkthrough alongside the change, the review runs in walk mode and the panel shows the current entry: the file, its position in the order the author chose, whether they marked it key, and the why they wrote for it. The full sequence — and the files the walkthrough doesn't cover — is one keystroke away in a quick pick, and commands jump to the file, advance and go back without leaving the editor.

The files the range touches, when it doesn't. A review without a walkthrough runs in whole mode, and there the panel is the list of changed files: a row opens that file's diff, and one control above them opens every change at once. The last row you opened stays marked, so a list you are halfway through still says where you were after closing the editor.

Your other reviews, when this branch has none. With no review on the current branch the panel lists the ones open elsewhere in the repository — active and saved, with their mode and position — so a review you put aside doesn't have to be remembered by name. Saved ones offer Continue; an active one is listed without an action, because going back to it is a branch checkout and the editor's branch picker already does that.

Getting started

1. Install the CLI. With Node:

   npm install -g git-review-workflow
   

   Homebrew, a native Windows (PowerShell) installer and a no-Node one-liner are all in the installation guide.

2. Tell it where PRs are integrated, once per repository — from the panel (git review: Set the Base Branch) or on the command line:

   git config reviewworkflow.base develop
   

3. Open the git review panel in the activity bar and hit Start a review. It asks for the branch, where to read it from, the range, and how to read it — offering only the layouts the CLI reports as viable for that PR. (Or run git review start feature/login in a terminal; the panel follows.)

Panel actions

Everything below is a command the panel exposes. Lifecycle actions (Finish, Save, Cancel, Preview and Refresh) are icon buttons on the view title bar; the rest are buttons inside the panel or entries in the Command Palette, all under the git review category.

Each one shells out to the matching git review verb — the extension never invents a second way to change review state.

Mutations (the lifecycle actions, clean, forget, compare and writing a walkthrough) ask for a confirmation that names what will happen. Preview is read-only and does not.

A finished review is not the empty state: the panel names where your staged edits landed — review-fixes/<branch>, or the PR branch itself with --onto-source — and offers Clean (drop the leftover undo point, keep the edits) or Undo finish. Commit and push those edits from Source Control as usual. A finish stopped mid-conflict keeps the review readable (mode, branch, current entry) but locks navigation until you Continue or Undo finish.

Requirements

• VS Code 1.75 or newer.
• git-review-workflow 0.4.0 or newer, discoverable as a git subcommand (git review -h works), or pointed at directly with the gitReview.path setting.
• A single-folder workspace. Multi-root workspaces are not supported: the panel needs exactly one git repository root, the same way the CLI has one cwd. Open the repository folder on its own, or pick one root and open that.
• On Windows the CLI itself runs under Git Bash, which Git for Windows provides.

Settings

gitReview.path on Windows

On Windows, a bare POSIX path such as …/bin/git-review — no .cmd, .bat or .exe extension — is spawned through sh, which only works if Git Bash's sh is on your PATH. Prefer one of:

• leave gitReview.path empty and install the CLI so that git review works as a subcommand (npm or the PowerShell installer both set that up), or
• point gitReview.path at a Windows-native shim — the .cmd an npm global install leaves behind, for example.

If spawning fails with ENOENT while gitReview.path points at an extensionless file, the cause is the missing sh, not a missing CLI.

Troubleshooting

The panel reports what it found rather than failing silently — a missing CLI, a version too old, a repository with no base configured — and offers the action that fixes it. When you need the detail, git review: Show CLI Log prints every invocation the extension made and what came back.

Learn more

• Project README — the full command surface, the walkthrough format, and how the workflow fits together. Also in Spanish.
• Website
• Issues
• Contributing to the extension — running it from source, tests, and the panel preview.

License

MIT © EzeVillo