GitHub
pull request
unified diff
version control
code review

Download Github pull request as unified diff

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

Downloading a GitHub pull request as a unified diff is useful when you want to review changes offline, archive a patch, or apply the change to another clone without using the GitHub UI. A pull request is still just a change set between two Git states, and GitHub exposes that change set directly in diff-friendly formats.

What a Unified Diff Actually Is

A unified diff is a text representation of file changes. It shows which files changed, where each edit happened, and which lines were added or removed.

Important line prefixes:

  • '--- and +++ identify the old and new file paths.'
  • '@@ identifies the changed hunk location.'
  • '- marks removed lines.'
  • '+ marks added lines.'

Example:

diff
1diff --git a/app.py b/app.py
2index 4f3e0ab..8b3911d 100644
3--- a/app.py
4+++ b/app.py
5@@ -1,4 +1,5 @@
6 def greet(name):
7-    return "Hello " + name
8+    if not name:
9+        return "Hello"
10+    return "Hello " + name

This format is portable and works well with git apply, code review tools, and CI scripts.

Download the Pull Request Diff from GitHub

If a pull request URL looks like this:

https://github.com/OWNER/REPO/pull/123

You can download the unified diff by appending .diff:

bash
curl -L https://github.com/OWNER/REPO/pull/123.diff -o pr-123.diff

GitHub also exposes a patch view:

bash
curl -L https://github.com/OWNER/REPO/pull/123.patch -o pr-123.patch

In practice:

  • Use .diff when you want file-level changes.
  • Use .patch when you want commit-oriented patch data, often for git am.

Inspect the Diff Before Applying It

A downloaded diff is just a text file, so inspect it like any other patch.

bash
less pr-123.diff

If you want only the changed file list:

bash
grep '^diff --git' pr-123.diff

You should verify:

  • The patch targets the repository you expect.
  • The changed files match the pull request description.
  • The diff is still relevant to your current local branch state.

This check matters because a pull request diff can become stale relative to the latest base branch.

Apply the Diff to a Local Repository

If you already have the target repository cloned, validate first:

bash
git apply --check pr-123.diff

If the check succeeds, apply it:

bash
git apply pr-123.diff

--check is important because it tells you whether the patch still matches local files without modifying anything.

If you are working from the patch variant and want commit metadata preserved, use:

bash
git am pr-123.patch

Use git am only when the patch is structured as commits you want to replay.

Alternative: Fetch the Pull Request as a Branch

Sometimes a downloaded diff is not the best tool. If you have repository access, fetching the pull request ref gives you a real branch to inspect and test.

bash
git fetch origin pull/123/head:pr-123
git checkout pr-123

This is better when:

  • You need full commit history.
  • You want to rebase or merge normally.
  • You want to run tests against the exact pull request branch.

Use the unified diff when portability matters more than full Git history.

Use Diffs in Automation

Unified diffs are handy in security scanning or review automation because they can be downloaded without checking out a contributor branch.

Example script:

bash
1#!/usr/bin/env bash
2set -euo pipefail
3
4OWNER="octocat"
5REPO="hello-world"
6PR_NUMBER="123"
7OUT="pr-${PR_NUMBER}.diff"
8
9curl -L "https://github.com/${OWNER}/${REPO}/pull/${PR_NUMBER}.diff" -o "$OUT"
10git apply --check "$OUT"
11echo "Downloaded and validated $OUT"

This keeps review workflows simple in isolated build environments.

Diff Versus Patch in Practice

Both formats represent the same change set, but they are optimized for slightly different uses.

  • '.diff is ideal for inspection and git apply.'
  • '.patch is ideal when email-style commit information matters.'

Choosing the right one avoids awkward tooling mismatches later.

Common Pitfalls

  • Downloading the pull request HTML page instead of the .diff or .patch endpoint.
  • Applying the diff against the wrong branch state.
  • Using git am when you only need raw file changes.
  • Skipping git apply --check and discovering conflicts after modification.
  • Assuming a downloaded diff proves the pull request still merges cleanly with the latest base branch.

Summary

  • GitHub pull requests can be downloaded directly as .diff or .patch.
  • Unified diffs are portable text files that show file changes with context.
  • 'git apply --check is the safest way to validate before applying locally.'
  • Use .patch with git am when commit metadata matters.
  • Fetch the pull request branch instead when you need full Git workflow rather than a portable patch file.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.