The Challenge of Code Collaboration
Before the invention of modern, centralized version control systems like Git and GitHub, collaborating on software development was incredibly difficult. If a programmer in Berlin found a bug in a massive open-source project managed by a programmer in New York, they could not easily push their fix to a shared cloud repository.
Instead, the Berlin programmer would have to download the original C code, make the changes locally, and somehow send those exact changes to New York. Emailing the entire, massive project folder back and forth was a massive waste of bandwidth.
The solution was the diff command, which generated a tiny text file (called a “patch”) containing only the exact lines of code that were added or deleted. When the New York programmer received this tiny patch file in an email, they needed a way to automatically apply those specific changes to their own local copy of the code. This is exactly what the patch command was built for.
Step 1: Understanding the Patch File
A patch file (often ending in .patch or .diff) is not an executable script. It is simply a roadmap of text changes. If you open a patch file in a text editor, you will see lines starting with a minus sign (-) indicating code that should be deleted, and lines starting with a plus sign (+) indicating code that should be added.
Assume you have an original script named server_config.sh, and a colleague emails you a file named security_update.patch which contains the bug fixes.
Step 2: Applying the Patch
To safely apply the changes from the patch file to your original script, you use the patch command and use the input redirect symbol (<) to feed the patch data into the tool.
patch server_config.sh < security_update.patch
The terminal will instantly reply: “patching file server_config.sh”.
The patch command automatically reads the roadmap, finds the exact line numbers in your original file, deletes the broken code, and inserts the new code. Your local script is now perfectly updated.
Step 3: Reversing a Patch
If you apply a patch from the internet, and suddenly your server script completely stops working, you need to instantly undo the changes and revert the file back to its original state.
Because a patch file contains both the old code (the minus lines) and the new code (the plus lines), the patch command can mathematically run the entire process in reverse.
To undo a patch you just applied, use the -R (Reverse) flag, and feed it the exact same patch file.
patch -R server_config.sh < security_update.patch
The terminal will reply: “patching file server_config.sh” (even though it is technically un-patching it). If you open your script, you will see it has been flawlessly reverted to its original, working state.
Step 4: Handling Rejected Hunks
The patch command is incredibly smart, but it can fail. If you try to apply security_update.patch, but your original server_config.sh file has already been heavily modified by someone else, the line numbers will not match up. The patch command will get confused and refuse to apply the change.
When this happens, the terminal will output an error: “Hunk #1 FAILED.”
To prevent catastrophic data loss, the patch command will leave your original file completely untouched. Instead, it will automatically generate a brand new file called server_config.sh.rej (Rejected). This file contains the exact snippet of code that confused the system, allowing you to open it manually and figure out where the code was actually supposed to go.