Home / Alt manpages / gh-pr-diff(1)

  • gh-pr-diff(1)
  • User command
  • linux

Read a Pull Request Diff with gh pr diff

gh pr diff shows a GitHub pull request's changes right in your terminal, no browser tab required. It also lists just the touched files, and opens the same diff in a browser when the terminal view falls short. The examples use GitHub CLI 2.87.3, the version installed on this machine.

Allow about ten minutes. You need gh, access to the repository, a network connection, and a pull request number, URL, or branch name. The commands only read pull request data, except that --web launches your browser. No sudo is required.

1. Check the installed command

Confirm the binary and version before relying on option names in a script, an ordinary read-only check:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

The relevant command is gh pr diff. Its installed manual accepts a pull request number, URL, or branch as the optional argument. Omit that argument, and it selects the pull request belonging to the current branch.

Checkpoint

Make sure you are in the repository you mean to inspect, or plan to pass --repo explicitly. A successful command against the wrong repository is still the wrong review.

2. Show a pull request patch

Replace 123 with the pull request number in the repository you intend to review:

$ gh pr diff 123

The output is a diff for the selected pull request, normally longer than a terminal window, so pipe it to a pager when reviewing interactively:

$ gh pr diff 123 | less

Press q to leave less. The command writes the diff to standard output, so you can redirect it to a temporary review file if needed:

$ gh pr diff 123 > /tmp/pr-123.diff
$ test -s /tmp/pr-123.diff && echo "diff captured"
diff captured

Capturing output does not change the pull request. Treat a diff file as potentially sensitive: it may carry credentials accidentally committed in a patch, private source, or configuration values. Remove it from /tmp after review if it should not stay on the machine:

$ rm -- /tmp/pr-123.diff

That removal is irreversible. Check the exact path before running a destructive command, and do not substitute a broad directory for the file shown here.

3. Select the pull request unambiguously

The optional argument can be a number, a pull request URL, or a branch. A URL helps when the repository is not obvious from your current directory:

$ gh pr diff https://github.com/OWNER/REPOSITORY/pull/123

For a branch, use the branch name exactly as GitHub knows it:

$ gh pr diff feature/example-change

With no argument, the command uses the pull request tied to the current branch:

$ git branch --show-current
feature/example-change
$ gh pr diff

Do not rely on the no-argument form when the branch has several related pull requests, or you are in a detached checkout. Supply the number or full URL and remove the ambiguity.

4. Pin the repository when the directory is confusing

Use -R or --repo with the [HOST/]OWNER/REPO form when the current directory is not the repository you want:

$ gh pr diff 123 --repo OWNER/REPOSITORY
$ gh pr diff 123 -R OWNER/REPOSITORY

For a GitHub Enterprise host, include the host component if that is how your gh installation identifies it:

$ gh pr diff 123 --repo github.example.net/OWNER/REPOSITORY

Checkpoint

Compare the owner, repository, and pull request number with the review request before interpreting the patch. The command needs access to the selected repository. If it reports an access or authentication failure, fix that separately; do not respond by changing repository settings or copying credentials into a command line.

5. Reduce the output to filenames

When you first want to establish scope, use --name-only. It prints the names of changed files without the line-by-line patch:

$ gh pr diff 123 --name-only
src/example.go
tests/example_test.go
README.md

The filenames above are illustrative; your output depends on the pull request. This is a useful checkpoint before reading a large change: a surprising path, generated file, or unexpected documentation change may deserve investigation before you spend time on the code.

6. Control colour and patch presentation

The colour option controls terminal colour and accepts always, never, or auto, the installed default:

$ gh pr diff 123 --color never | less
$ gh pr diff 123 --color always
$ gh pr diff 123 --color auto

Use never for logs, captured files, or tools that do not interpret terminal colour sequences. Use auto for normal interactive work. For a command whose consumer explicitly expects a patch representation, add --patch:

$ gh pr diff 123 --patch --color never > /tmp/pr-123.patch

Disabling colour changes presentation, not content: it does not change the selected pull request or its files.

7. Open the diff in a browser when required

Use -w or --web to open the pull request diff in your configured browser:

$ gh pr diff 123 --web
$ gh pr diff 123 --repo OWNER/REPOSITORY --web

This hands the selected pull request to a browser. It does not edit, approve, merge, or close the pull request. Treat the URL as sensitive if the repository is private, and check the host and repository before opening a link copied from elsewhere.

8. Diagnose the usual mistakes

  • Unexpected change selected. Stop, print the current branch, then repeat with an explicit number and repository.
    $ git branch --show-current
    $ gh pr diff PULL_REQUEST_NUMBER --repo OWNER/REPOSITORY --name-only
  • "Pull request cannot be found." Check the number, owner, repository, host, and your access to the repository.
  • No useful terminal colours. That is usually a presentation setting rather than an empty diff; try always interactively or leave the default at auto.

Do not use --web as a substitute for checking the target. Browser history makes it easy to overlook a wrong owner or repository, especially when several projects use the same branch names.

Done means

  • Version and target checked. You confirmed the installed gh version and repository target.
  • Pull request selected on purpose. You reviewed it by number, URL, or an intentionally chosen branch.
  • Scope established first. You used --name-only to check the file scope before reading a large patch.
  • Colour setting matched the use. You chose never for captured output and understood the auto default.
  • Repository pinned when needed. You used --repo when the current directory could identify the wrong project.
  • Temporary files cleaned up. Any diff file has been checked, handled as sensitive data, and removed once no longer needed.