Learning how to apply a patch in git safely means treating the patch file the way you'd treat any other unreviewed input: check it before it touches your working tree, apply it in a way that fails loudly if something's wrong, and verify the result before you commit. git apply and git am will happily apply a patch that half-conflicts with your tree unless you take a few extra steps.
A patch is just a text diff, typically produced by git diff or git format-patch, describing changes to apply to a set of files. The two main tools for applying one are git apply, which applies a diff to the working tree without touching history, and git am, which applies a series of patches as commits, preserving author information and commit messages. Picking the right one for the situation matters more than most people assume.
When should you use git apply vs git am?
Use git apply when you have a raw diff, say, something pulled from a code review comment, a bug report, or a one-off patch file, and you just want the changes in your working directory without creating a commit. Use git am when you have output from git format-patch, which includes commit metadata, and you want to replay that history as actual commits with the original author preserved. This distinction matters because git am will fail differently than git apply on a malformed patch, and mixing them up produces confusing error messages that don't point at the real problem.
A common mistake is applying a format-patch output with plain git apply --index because it seems to work, then later realizing the commit history and attribution never got created. If you care about preserving who wrote a fix and why, git am is the correct tool.
How do you check a patch before applying it?
Before applying anything, run git apply --check patch.diff. This performs a dry run: it reports whether the patch would apply cleanly without actually modifying any files. If it reports conflicts, you'll want to know exactly where before committing to the apply, since a failed application can leave stray .rej reject files scattered in your tree if you're not careful.
It's also worth reading the diff itself, not just running the tool. Patches from untrusted sources, a GitHub issue, a mailing list, an AI-generated suggestion, can contain more than the described change. This is the same discipline you'd apply to reviewing a pull request: read the actual diff content, not just the summary, especially for anything touching build scripts, CI configuration, or dependency manifests, since that's where a malicious patch is most likely to smuggle in something unwanted.
What if the patch doesn't apply cleanly?
If git apply --check reports failures, a few options exist depending on how far off the patch is. git apply --3way attempts a three-way merge using the blob information embedded in the patch, which often succeeds where a straight apply fails because the target file has drifted slightly since the patch was generated. It will leave conflict markers in the file for you to resolve manually if it can't fully reconcile the changes, similar to a merge conflict.
For patches that are badly out of date relative to your current tree, it's often faster to manually reapply the underlying change than to fight with git apply. And if the patch touches a file that doesn't exist in your tree, git apply will simply fail, at which point you need to decide whether the patch is even relevant to your current codebase.
How does this connect to JSON patch and API-level changes?
The same "verify before applying" discipline applies outside of Git. JSON Patch, defined in RFC 6902, describes a sequence of operations, add, remove, replace, move, copy, test, applied to a JSON document, and it's commonly used in REST APIs for partial updates. Just as with a Git patch, you want to validate a JSON Patch document against the target resource's current state before applying it in production, particularly the test operation, which exists precisely to guard against applying a patch against a document that has changed since the patch was generated.
Whether it's a Git diff or a JSON Patch, the underlying principle is the same: a patch encodes an assumption about the state it's being applied to, and skipping validation is how that assumption silently breaks something.
Where patch hygiene fits into a broader security posture
Applying third-party patches without review is a real supply-chain risk vector, especially in open-source projects that accept community-submitted diffs. Static analysis on the resulting code, after a patch lands, catches issues a visual diff review might miss, and it's worth running your normal SAST pipeline against any branch that incorporates externally sourced patches before merging to a protected branch.
FAQ
What's the difference between git apply and git am?
git apply applies a diff to your working tree without creating commits. git am applies patches generated by git format-patch as full commits, preserving author and message metadata.
How do I undo a patch after applying it?
If you used git apply, run git apply -R patch.diff to reverse it, provided the working tree hasn't changed further. If you used git am, reset with git reset --hard to a commit before the applied patches, or revert the specific commits.
Why did my patch leave .rej files?
.rej files are created when git apply can't cleanly apply certain hunks and falls back to a legacy patch-tool behavior of writing the rejected hunks to a separate file. Use --3way instead to get inline conflict markers, which are usually easier to resolve.
What is JSON Patch and how does it relate to Git patches?
JSON Patch is an RFC 6902 format for describing partial updates to a JSON document via operations like add, remove, and replace. It shares the same core risk as a Git patch: applying it against a document whose state has drifted can produce unexpected results, so validating first matters in both cases.