Linux patch Command: Apply Diff Files

When someone sends you a fix for a source file or a configuration file, it often arrives as a small diff file instead of a full copy of the file. The diff lists only the lines that changed, so it is easy to review, email, or attach to a bug report.

The patch command reads that diff file and applies the changes to your original files. It is the standard way to distribute and apply source code changes, security fixes, and configuration updates in Linux, and pairs directly with the diff command.

This guide explains how to use the patch command in Linux with practical examples.

Syntax #

The general syntax of the patch command is:

patch [OPTIONS] [ORIGINALFILE] [PATCHFILE]

You can pass the patch file using the -i option or pipe it through standard input:

patch [OPTIONS] -i patchfile [ORIGINALFILE]
patch [OPTIONS] [ORIGINALFILE] < patchfile

patch Options #

Create and Apply a Basic Patch #

The most common workflow is to use diff to generate a patch file and patch to apply it.

Start with two versions of a file. Here is the original:

print("Hello, World!")
print("Version 1")

And the updated version:

print("Hello, Linux!")
print("Version 2")

Use diff with the -u flag to generate a unified diff and save it to a patch file:

diff -u hello.py hello_new.py > hello.patch

The hello.patch file will contain the following differences:

--- hello.py    2026-02-21 10:00:00.000000000 +0100
+++ hello_new.py        2026-02-21 10:05:00.000000000 +0100
@@ -1,2 +1,2 @@
-print("Hello, World!")
-print("Version 1")
+print("Hello, Linux!")
+print("Version 2")

The first two lines are the header. The --- line names the original file and the +++ line names the new file, each followed by a timestamp. The @@ -1,2 +1,2 @@ line marks the start of a hunk. It means that two lines starting at line 1 in the original file are replaced with two lines starting at line 1 in the new file.

Lines starting with - are removed, and lines starting with + are added. In larger patches, you will also see unchanged context lines that start with a space. patch uses them to find the right place in the file.

To apply the patch to the original file:

patch hello.py hello.patch

patching file hello.py

hello.py now contains the updated content from hello_new.py.

Dry Run Before Applying #

Use --dry-run to test whether a patch will apply cleanly without actually modifying any files. If you applied the patch in the previous example, reverse it first to restore the original hello.py:

patch -R hello.py hello.patch

Now run the dry run against the unpatched file:

patch --dry-run hello.py hello.patch

checking file hello.py

patch prints checking file instead of patching file, and hello.py stays unchanged. If the patch cannot be applied cleanly, patch reports the conflict without touching any files. This is useful before applying patches from external sources or when you are unsure whether a patch has already been applied.

Back Up the Original File #

Use the -b option to create a backup of the original file before applying the patch. The backup is saved with a .orig extension:

patch -b hello.py hello.patch

patching file hello.py

After running this command, hello.py.orig contains the original unpatched file. You can restore it manually if needed.

Strip Path Components with -p #

When a patch file is generated from a different directory structure than the one where you apply it, the file paths inside the patch may not match your local paths. Use -p N to strip N leading path components from the paths recorded in the patch.

For example, a patch generated with git diff will reference files like:

--- a/src/utils/hello.py
+++ b/src/utils/hello.py

To apply this patch from the project root, use -p1 to strip the a/ and b/ prefixes:

patch -p1 < hello.patch

-p1 is the standard option for patches generated by git diff and by diff -ruN run from the parent directory of the two project trees. Without it, patch would look for a file named a/src/utils/hello.py on disk, which does not exist.

Reverse a Patch #

Use the -R option to undo a previously applied patch and restore the original file:

patch -R hello.py hello.patch

patching file hello.py

The file is restored to its state before the patch was applied.

Apply a Multi-File Patch #

A single patch file can contain changes to multiple files. To create one, run diff on two directories from their parent directory:

diff -ruN project_old project_new > project.patch

The options used are:

• -r - Compare directories recursively
• -u - Produce a unified diff
• -N - Treat missing files as empty, so files that exist only in project_new are included as new files

To apply a multi-file patch, you do not specify a target file on the command line. patch reads the file names from the diff headers inside the patch. Change into the directory you want to update and run:

patch -p1 < ../project.patch

patching file README.md
patching file src/app.py

patch processes each file name from the diff headers and applies the corresponding changes. The paths in the patch start with project_old/ and project_new/, so -p1 strips that first component. The same applies to patches produced by git diff.

Quick Reference #

Troubleshooting #

Hunk #1 FAILED at N.
The patch does not match the current content of the file. This usually means the file has already been modified since the patch was created, or you are applying the patch against the wrong version. patch creates a .rej file containing the failed hunk so you can review and apply the change manually.

Reversed (or previously applied) patch detected! Assume -R?
patch has detected that the changes in the patch are already present in the file. The patch may have been applied before. Answer y to reverse the patch or n to skip it. Use -N (--forward) to automatically skip already-applied patches without prompting.

patch: **** malformed patch at line N
The patch file is corrupted or incomplete. This often happens when an email client or editor changes tabs, line endings, or trailing whitespace. patch detects normal, context, and unified diffs automatically, so the format itself is rarely the cause. Download the patch again or ask the sender for a fresh copy.

File paths in the patch do not match files on disk.
Adjust the -p N value. Run patch --dry-run -p0 < changes.patch first, then increment N (-p1, -p2) until patch finds the correct files.

patch: command not found
Minimal installs and container images often ship without patch. Install it with sudo apt install patch on Ubuntu, Debian, and Derivatives, or with sudo dnf install patch on Fedora, RHEL, and Derivatives.

FAQ #

How do I create a patch file?
Use the diff command with the -u flag: diff -u original.txt updated.txt > changes.patch. The -u flag produces a unified diff, which is the format patch works with by default. See the diff command guide for details.

What does -p1 mean?
-p1 tells patch to strip one leading path component from file names in the patch. Patches generated by git diff prefix file paths with a/ and b/, so -p1 removes that prefix before patch looks for the file on disk.

How do I undo a patch I already applied?
Run patch -R originalfile patchfile. patch reads the diff in reverse and restores the original content.

What is a .rej file?
When patch cannot apply one or more sections of a patch (called hunks), it writes the failed hunks to a file with a .rej extension alongside the original file. You can open the .rej file and apply those changes manually.

What is the difference between patch and git apply?
Both apply diff files, but git apply is designed for use inside a Git repository and integrates with the Git index. patch is a standalone POSIX tool that works on any file regardless of version control.

Conclusion #

The patch command is the standard tool for applying diff files in Linux. Use --dry-run to verify a patch before applying it, -b to keep a backup of the original, and -R to reverse changes when needed. For patches inside a Git repository, see our guide on the git diff command .

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page