How to Review Pull Requests in VS Code (2026)

Why review PRs in VS Code?

The GitHub and GitLab web interfaces are fine for small pull requests. You open the diff, scan a few dozen lines, leave a comment, and approve. But the moment a PR grows beyond a hundred lines or touches unfamiliar code, the web browser becomes a constraint rather than a tool. You cannot jump to a function definition. You cannot search across the full codebase for other callers of a modified function. You cannot run the test suite against the changed code. You cannot set a breakpoint and step through the logic to verify that an edge case is handled correctly.

VS Code eliminates every one of those limitations. When you review a pull request inside VS Code, you get the full power of an IDE applied to the review process. IntelliSense shows you type information and function signatures as you read through changed files. Go-to-definition lets you trace a function call to its implementation in a single click. Find All References shows you every place in the codebase that calls the function being modified, so you can assess the blast radius of a change. The integrated terminal lets you run the code locally, execute the test suite, and verify behavior before you approve.

There are three concrete scenarios where VS Code review is significantly better than the web interface:

Large PRs with cross-file dependencies. When a PR modifies a service, its tests, its API contract, and a consuming component, you need to hold the relationships between those files in your head. VS Code's file explorer, multi-tab layout, and split editor make it possible to view related files side by side while navigating the diff.

Unfamiliar code. When you are reviewing code in a part of the codebase you do not work in regularly, you need to explore the surrounding context to understand what the change is doing. Go-to-definition, Peek Definition, and Find All References let you build that context without leaving the review flow.

Performance and correctness verification. Sometimes you cannot tell whether code is correct just by reading it. You need to run it. VS Code lets you check out the PR branch, run the application locally, execute specific test cases, and even use the debugger to step through the changed code. This level of verification is impossible from a web browser.

The rest of this guide walks through the complete setup and workflow for reviewing pull requests in VS Code, covering GitHub PRs, GitLab merge requests, and the extensions that make the process efficient.

Setting up the GitHub Pull Requests extension

The GitHub Pull Requests and Issues extension is the official extension built by GitHub for reviewing PRs directly in VS Code. It is the foundation of the VS Code review workflow for any team using GitHub.

Installation

Open VS Code and press Ctrl+Shift+X (Windows/Linux) or Cmd+Shift+X (macOS) to open the Extensions panel. Search for "GitHub Pull Requests" and install the extension published by GitHub. The extension ID is GitHub.vscode-pull-request-github. Alternatively, install it from the command line:

code --install-extension GitHub.vscode-pull-request-github

After installation, VS Code will display a new "GitHub Pull Requests" icon in the Activity Bar on the left side of the window.

Authentication

The first time you click the GitHub Pull Requests icon, VS Code will prompt you to sign in to GitHub. Click "Sign in" and follow the OAuth flow in your browser. VS Code will request permissions to read your repositories, pull requests, and issues. Approve the permissions, and VS Code will store the authentication token securely in your system's credential store.

If you work with multiple GitHub accounts (for example, a personal account and a work account), you can add additional accounts through the Accounts menu in the bottom-left corner of VS Code. The extension will use the account that matches the remote URL of the repository you have open.

To verify that authentication is working, open a repository that has open pull requests and check that the GitHub Pull Requests panel in the sidebar shows a list of PRs. If the list is empty but you know there are open PRs, check that the repository's remote URL points to GitHub and that your authenticated account has access to the repository.

Configuration options

The extension has several settings that are worth configuring before you start reviewing. Open VS Code settings (Ctrl+, or Cmd+,) and search for "github pull requests" to see all available options.

The most important settings:

{
  "githubPullRequests.defaultMergeMethod": "squash",
  "githubPullRequests.showPullRequestNumberInTree": true,
  "githubPullRequests.fileListLayout": "tree",
  "githubPullRequests.pullBranch": "prompt",
  "githubPullRequests.notifications": "pullRequests",
  "githubPullRequests.assignCreated": true
}

• defaultMergeMethod controls which merge strategy is used when you merge a PR from VS Code. Options are merge, squash, and rebase. Match this to your team's convention.
• fileListLayout controls whether changed files are shown as a flat list or a tree. The tree view is more useful for PRs that touch files across multiple directories.
• pullBranch determines whether VS Code automatically checks out the PR branch or prompts you first. Set this to prompt if you often have uncommitted changes that you do not want to lose.
• notifications controls which GitHub notifications appear in VS Code. Set to pullRequests to see only PR-related notifications.

Reviewing a pull request step by step

This section walks through the complete workflow for reviewing a pull request in VS Code, from opening the PR to merging it.

Step 1: Find and open the PR

Click the GitHub Pull Requests icon in the Activity Bar. The sidebar shows a tree of pull requests organized by category: "Local Pull Request Branches" (PRs you have already checked out), "Waiting For My Review," "Assigned To Me," "Created By Me," and "All Open." Expand "Waiting For My Review" to see PRs that need your attention.

Click on a PR to open its description in the editor. The description view shows the PR title, body, labels, reviewers, checks status, and a list of changed files. This view is similar to what you see on GitHub's web interface, but it is embedded in your IDE.

Step 2: Check out the PR branch

To get full IDE features during review, check out the PR branch locally. Right-click the PR in the sidebar and select "Checkout Pull Request," or click the "Checkout" button in the PR description view. VS Code will fetch the branch from the remote and switch to it.

Once the branch is checked out, you have the full codebase at the PR's state. You can run the application, execute tests, use the debugger, and navigate the code exactly as you would during normal development. This is the single biggest advantage of VS Code review over the web interface.

If you do not want to check out the branch (for example, you have work in progress on your current branch), you can still review the diff and leave comments without checking out. The extension supports a "virtual checkout" mode where it fetches the diff remotely and displays it in VS Code without modifying your local branch. You lose the ability to run the code locally, but you keep all the IDE features like IntelliSense and go-to-definition within the changed files.

Step 3: View file changes

After checking out the PR, the sidebar shows a list of changed files. Click on any file to open a side-by-side diff view. The left pane shows the base branch version and the right pane shows the PR branch version. Changed lines are highlighted in green (additions) and red (deletions).

You can navigate between changed files using several methods:

• Click files in the sidebar tree.
• Use Alt+F5 (or Option+F5 on macOS) to jump to the next changed file.
• Use F7 to move to the next change within the current file.
• Use Shift+F7 to move to the previous change within the current file.

The diff view supports all standard VS Code features. You can hover over symbols to see type information, press F12 to go to a definition, press Shift+F12 to find all references, and use Ctrl+Shift+F to search across the entire codebase. These features are what make VS Code review fundamentally more powerful than web-based review for complex PRs.

Step 4: Leave inline comments

To leave a comment on a specific line, hover over the line number in the diff view and click the blue + icon that appears. A comment box opens where you can type your feedback. You can use Markdown formatting, mention other users with @username, and include code snippets with triple backticks.

Comments can be left on individual lines or on ranges of lines. To comment on a range, click the + icon on the first line, then drag to select multiple lines before typing your comment.

Each comment you write is part of a pending review. This means your comments are not posted immediately. They are batched and submitted together when you complete your review, just like the web interface. This lets you write all your feedback before the PR author sees any of it, avoiding the frustrating experience of receiving review comments one at a time.

You can also start a new comment thread from the command palette. Press Ctrl+Shift+P (or Cmd+Shift+P) and type "Add Review Comment" to start a comment on the current line.

Step 5: Approve, request changes, or comment

Once you have finished reviewing all changed files and written your comments, submit your review. Open the command palette and type "Submit Review" or click the "Submit Review" button in the PR description view. VS Code presents three options:

• Approve - You are satisfied with the changes and they are ready to merge.
• Request Changes - There are issues that must be addressed before the PR can merge.
• Comment - You have feedback but are not formally approving or blocking the PR.

Select the appropriate option, optionally add a summary comment, and submit. Your review and all pending inline comments are posted to GitHub simultaneously.

Step 6: Merge from VS Code

After the PR is approved and all required checks have passed, you can merge it directly from VS Code. Click the "Merge Pull Request" button in the PR description view. VS Code will use the merge method specified in your defaultMergeMethod setting (merge commit, squash, or rebase). You can also choose a different method from the dropdown next to the merge button.

After merging, VS Code will offer to delete the remote branch and switch back to the default branch. Accept both to keep your repository clean.

GitLens for enhanced reviews

GitLens is the most popular Git extension for VS Code, with over 30 million installs. While the GitHub Pull Requests extension handles the PR workflow, GitLens enhances the review experience with deeper Git integration.

File history

During a review, you often need to understand the history of a file to determine whether the current changes are consistent with the file's evolution. GitLens adds a "File History" view to the sidebar that shows every commit that modified the current file, with diffs for each change. This is invaluable when you are reviewing a refactoring PR and want to verify that the refactoring preserves the original behavior.

Right-click any file in the explorer and select "Open File History" to see its full commit history. You can click on any commit to see the diff for that specific change.

Line blame during review

GitLens adds inline blame annotations that show who last modified each line and when. During review, this tells you how old the surrounding code is and who wrote it. If a PR modifies a function and the blame shows that the surrounding code was last touched three years ago by someone no longer on the team, that context helps you understand whether the change is a simple fix or a risky modification to rarely-touched code.

Enable inline blame with the setting:

{
  "gitlens.currentLine.enabled": true,
  "gitlens.currentLine.format": "${author}, ${agoOrDate} • ${message}"
}

With this setting, every line you look at during a review shows who wrote it, when, and the commit message that introduced it. This context is invisible in the web interface and is one of the strongest arguments for reviewing in VS Code.

Commit-by-commit review

For large PRs with multiple commits, reviewing the entire diff at once can be overwhelming. GitLens lets you review each commit individually. In the GitLens sidebar, expand the "Commits" view to see all commits in the PR branch. Click on any commit to see only the changes introduced by that specific commit.

This approach is particularly effective when the PR author has organized their work into logical commits. You can review the database migration commit separately from the application code commit, focusing on the concerns relevant to each layer.

Copilot-assisted review in VS Code

GitHub Copilot has evolved from a code completion tool into a comprehensive AI coding assistant that includes code review capabilities. When you review a PR in VS Code with Copilot enabled, you get AI-powered insights alongside your own analysis.

AI suggestions during review

Copilot can analyze the changes in a PR and provide suggestions for improvements. When you have the GitHub Pull Requests extension and Copilot both installed, you can request a Copilot review on any open PR. In the PR description view, click the "Reviewers" section and add Copilot as a reviewer.

Copilot will analyze the diff and post inline comments highlighting potential bugs, security issues, performance concerns, and code quality improvements. These comments appear alongside human review comments and can be resolved or dismissed like any other review comment.

You can also highlight a specific block of code in the diff view, right-click, and select "Copilot: Explain This" to get an AI-generated explanation of what the code does. This is particularly useful when reviewing unfamiliar code or complex algorithms.

Chat-based code analysis

Copilot Chat provides an interactive way to analyze code during review. Open the Copilot Chat panel (Ctrl+Shift+I or Cmd+Shift+I) and ask questions about the code you are reviewing:

• "What does this function do?" with a code selection will produce a detailed explanation.
• "Are there any edge cases this code does not handle?" will identify potential gaps.
• "Could this code have any security vulnerabilities?" will flag common security patterns.
• "Suggest a more efficient way to write this" will propose performance improvements.

The chat interface maintains context across your conversation, so you can ask follow-up questions like "What would happen if userId is null in that function?" without re-selecting the code.

For review workflows specifically, try this pattern: select all changed lines in a file, open Copilot Chat, and type "Review this code change for bugs, security issues, and performance problems." Copilot will provide a structured analysis that you can use as a starting point for your own review.

Reviewing GitLab merge requests in VS Code

Teams using GitLab have a similar workflow available through the GitLab Workflow extension. While the experience is not as polished as the GitHub extension (which is built by GitHub itself), it covers the core review workflow.

GitLab Workflow extension setup

Install the GitLab Workflow extension from the VS Code marketplace. The extension ID is GitLab.gitlab-workflow. After installation, you need to configure your GitLab instance URL and a personal access token.

1. Generate a personal access token in GitLab: navigate to Settings, then Access Tokens, and create a token with api and read_user scopes.
2. In VS Code, open the command palette and type "GitLab: Set GitLab Personal Access Token."
3. Enter your GitLab instance URL (for example, https://gitlab.com or your self-hosted URL).
4. Paste the personal access token.

The extension will connect to your GitLab instance and display merge requests for the current repository in the sidebar.

MR review workflow

The GitLab Workflow extension supports the core review actions:

• View MR list. The sidebar shows merge requests assigned to you, created by you, and all open MRs for the current project.
• View MR diff. Click on an MR to see the list of changed files. Click on a file to open the diff view, which works identically to the GitHub extension's diff view.
• Leave comments. Hover over a line in the diff and click the comment icon to leave inline feedback. Comments are posted to GitLab as MR discussion threads.
• Approve MRs. Use the command palette action "GitLab: Approve Merge Request" to approve.
• Checkout MR branch. Right-click the MR and select "Checkout" to switch to the MR branch locally, enabling full IDE features and local code execution.

The extension also supports GitLab-specific features like viewing pipeline status, browsing CI/CD job logs, and creating snippets. For teams on GitLab, this extension makes it possible to stay in VS Code for the entire MR lifecycle without opening the GitLab web interface.

One limitation compared to the GitHub extension: the GitLab extension does not support submitting batched reviews. Comments are posted individually as you write them rather than being held until you submit a formal review. This means the MR author receives notifications for each comment rather than a single notification for the complete review. For most workflows this is a minor inconvenience, but it is worth knowing.

Keyboard shortcuts for fast reviews

Efficient code review in VS Code depends on keyboard shortcuts. Mouse-driven review is slow and breaks your reading flow. The following shortcuts will significantly speed up your review process.

Navigation shortcuts

Action	Windows/Linux	macOS
Open PR list	Ctrl+Shift+P then type "PR"	Cmd+Shift+P then type "PR"
Next changed file	Alt+F5	Option+F5
Previous changed file	Alt+Shift+F5	Option+Shift+F5
Next change in file	F7	F7
Previous change in file	Shift+F7	Shift+F7
Go to definition	F12	F12
Peek definition	Alt+F12	Option+F12
Find all references	Shift+F12	Shift+F12
Go back (after jump)	Alt+Left	Ctrl+-
Go forward	Alt+Right	Ctrl+Shift+-
Toggle inline diff/side-by-side	Ctrl+Shift+P then "Toggle Inline View"	Cmd+Shift+P then "Toggle Inline View"

Comment shortcuts

Action	Windows/Linux	macOS
Add review comment	Ctrl+Shift+P then "Add Review Comment"	Cmd+Shift+P then "Add Review Comment"
Submit review	Ctrl+Shift+P then "Submit Review"	Cmd+Shift+P then "Submit Review"
Toggle comment thread	Ctrl+Shift+P then "Toggle Comment Thread"	Cmd+Shift+P then "Toggle Comment Thread"

Custom keybindings

The default shortcuts for PR review are mostly accessed through the command palette, which requires typing. For faster access, bind the most common review actions to direct keyboard shortcuts. Open keybindings.json (Ctrl+K Ctrl+S, then click the open file icon in the top right) and add:

[
  {
    "key": "ctrl+shift+n",
    "command": "pr.goToNextDiffInPr",
    "when": "github:inReviewMode"
  },
  {
    "key": "ctrl+shift+p",
    "command": "pr.goToPreviousDiffInPr",
    "when": "github:inReviewMode"
  },
  {
    "key": "ctrl+shift+c",
    "command": "pr.createComment",
    "when": "github:inReviewMode"
  },
  {
    "key": "ctrl+shift+s",
    "command": "pr.submitReview",
    "when": "github:inReviewMode"
  }
]

The when clause github:inReviewMode ensures these shortcuts only activate when you are reviewing a PR, so they do not conflict with other shortcuts during normal editing.

Multi-repo workflows

Many engineering teams work with multiple repositories. A frontend repo, a backend repo, a shared library repo, and an infrastructure repo are common. When a feature spans multiple repos, the PRs across those repos need to be reviewed together to understand the full change.

Workspaces with multiple repos

VS Code workspaces let you open multiple repository folders in a single VS Code window. Create a workspace file that includes all your related repositories:

{
  "folders": [
    { "path": "/Users/you/code/frontend" },
    { "path": "/Users/you/code/backend" },
    { "path": "/Users/you/code/shared-lib" }
  ],
  "settings": {
    "githubPullRequests.queries": [
      {
        "label": "Waiting For My Review",
        "query": "is:open review-requested:${user}"
      },
      {
        "label": "All Open PRs",
        "query": "is:open"
      }
    ]
  }
}

Save this as a .code-workspace file and open it with File > Open Workspace from File. The GitHub Pull Requests extension will show PRs from all repositories in the workspace, giving you a unified view across repos.

This is powerful for cross-repo features. You can review the backend PR in one tab, switch to the frontend PR in another tab, and verify that the API contract matches across both repos. You can search across all repos simultaneously with Ctrl+Shift+F to find all callers of a modified API endpoint.

Reviewing across repos

When you have a multi-repo workspace open, the PR sidebar shows PRs grouped by repository. You can check out PR branches in different repos independently. For example, check out the feature/new-auth branch in the backend repo and the feature/new-auth-ui branch in the frontend repo simultaneously. Both repos are now at the state of their respective PRs, and you can run the full stack locally to verify end-to-end behavior.

This workflow is not possible in the web interface. On GitHub's web UI, you can only look at one PR at a time, in one repo at a time. VS Code's multi-repo workspace gives you a holistic view of cross-cutting changes.

For teams that frequently work across repos, consider customizing the PR queries in your workspace settings to filter by label or branch name prefix. For example, if your team uses a convention where related PRs across repos share the same branch name prefix:

{
  "githubPullRequests.queries": [
    {
      "label": "Feature: New Auth",
      "query": "is:open head:feature/new-auth"
    }
  ]
}

This filters the PR list to show only PRs related to the feature you are reviewing, cutting through the noise of unrelated open PRs.

VS Code review vs web UI: when to use each

VS Code and the web interface are not competitors. They are complementary tools suited to different situations. Using the right tool for each review saves time and improves review quality.

Comparison table

Factor	VS Code	Web UI (GitHub/GitLab)
Setup required	Extension install + auth	None (already authenticated)
Time to start reviewing	30-60 seconds (open VS Code, find PR, checkout)	5-10 seconds (click notification link)
IntelliSense / type info	Full support	Not available
Go-to-definition	Full support	Limited (GitHub Codespaces only)
Find all references	Full support	Not available
Run tests locally	Yes (after branch checkout)	No
Debugger support	Yes (after branch checkout)	No
Multi-file side-by-side view	Yes (split editor)	Limited (one file at a time)
Cross-repo review	Yes (workspaces)	No
Inline blame annotations	Yes (with GitLens)	Partial (blame view only, not in diff)
Comment threading	Full support	Full support
PR merge	Full support	Full support
Batch review submission	Yes	Yes
Suggested changes (code blocks)	Yes	Yes (with preview)
Review conversation history	Partial (current session)	Full history
Mobile review	No	Yes (mobile browser)
PR overview and summary	Basic	Rich (checks, deployments, labels, timeline)
CI/CD status and logs	Limited	Full access

Recommendations by PR size and complexity

Small PRs (under 100 lines, single file or simple changes). Use the web UI. The overhead of opening VS Code, checking out the branch, and navigating the PR is not justified when you can read the entire diff in a single browser scroll. Click the notification, scan the diff, leave a comment if needed, and approve. Total time: 2-5 minutes.

Medium PRs (100-400 lines, multiple files, straightforward logic). Either tool works. If you are already in VS Code working on the same codebase, use VS Code. If you are checking notifications on your phone or in between meetings, use the web UI. The deciding factor is convenience, not capability.

Large PRs (400+ lines, cross-file dependencies, complex logic). Use VS Code. Large PRs require the ability to navigate between files, trace function calls, and understand how changes in one file affect behavior in another. The web UI's one-file-at-a-time view is inadequate for this level of analysis. Check out the branch, use go-to-definition to trace dependencies, run the tests to verify correctness, and use GitLens blame to understand the history of the modified code.

PRs in unfamiliar code. Use VS Code. When you do not know the codebase well, you need IntelliSense to understand types, go-to-definition to trace call chains, and find-all-references to assess impact. These features are the difference between a confident review and a guess.

PRs that require running the code. Use VS Code. If you need to verify that a UI component renders correctly, that an API endpoint returns the right response, or that a database migration runs without errors, you need to run the code locally. Check out the branch, start the application, and test the behavior before approving.

Security-sensitive PRs. Use VS Code. Security review benefits from the ability to trace data flow through the application. When you see user input being processed, you want to follow it through every function call to verify that it is validated, sanitized, and never used in a dangerous context. Go-to-definition and find-all-references make this tractable. Doing the same analysis in the web UI requires manually opening each file and searching for function names.

Emergency hotfix PRs. Use the web UI. When production is down and someone has pushed a one-line fix, the last thing you want to do is wait for VS Code to start, fetch the branch, and build the project. Open the PR in your browser, verify the fix, approve, and merge. Speed matters more than thoroughness in this scenario.

A practical hybrid workflow

Many experienced reviewers use both tools in a single review session. They start in the web UI to read the PR description, understand the context, and scan the check results. If the PR is small and straightforward, they finish the review there. If it is large or complex, they switch to VS Code for the detailed review, then return to the web UI to check deployment status and merge.

This hybrid approach gives you the speed of the web UI for triage and the power of VS Code for deep analysis, without committing to either tool exclusively.

Further Reading

• Code Review Best Practices - The Complete Guide for Engineering Teams (2026)
• How to Automate Code Reviews in 2026 - Complete Setup Guide
• 12 Best Free Code Review Tools in 2026 - Open Source and Free Tiers
• GitHub Copilot Alternatives in 2026 - AI Coding Assistants Compared

Frequently Asked Questions

Can I review pull requests in VS Code?

Yes. Install the GitHub Pull Requests and Issues extension. It lets you check out PRs, view diffs, leave comments, approve or request changes, and merge — all without leaving VS Code.

What VS Code extensions are best for code review?

The essential extensions are: GitHub Pull Requests and Issues (official, by GitHub), GitLens (enhanced Git features, blame, history), and GitHub Copilot (AI-powered review suggestions). For GitLab users, GitLab Workflow extension provides similar MR review capabilities.

Can I use VS Code to review GitLab merge requests?

Yes. Install the GitLab Workflow extension from the VS Code marketplace. It supports viewing, commenting on, and approving merge requests directly in VS Code, similar to the GitHub Pull Requests extension.

Is reviewing PRs in VS Code better than the web interface?

VS Code review is better for large PRs where you need full IDE features — IntelliSense, go-to-definition, find references, and the ability to run the code locally. The web interface is faster for small PRs and provides a better overview. Many developers use both depending on PR complexity.

---

Originally published at aicodereview.cc