git-apply

Print messages about the patched files

$ git apply [[-v|--verbose]] [path/to/file]

$ git apply --index [path/to/file]

$ curl [[-L|--location]] [https://example.com/file.patch] | git apply

$ git apply --stat --apply [path/to/file]

$ git apply [[-R|--reverse]] [path/to/file]

$ git apply --cache [path/to/file]

git apply [<options>] [<patch>...]

-p<num>, --strip=<num>
    Strip the first <num> leading path components from file names in the patch.

-R, --reverse
    Apply the patch in reverse, effectively reverting the changes.

--cached
    Apply the patch directly to the Git index (staging area) without modifying the working tree. This prepares the changes for a commit without touching your local files.

--index
    Apply the patch to both the working tree and the index. This is useful when the patch involves modifications to files that are already staged.

--check
    Don't apply the patch; instead, check if it can be applied cleanly. This is useful for verifying patch compatibility before actual application.

--stat
    Show a diffstat (summary of changes) instead of applying the patch. Similar to the output of git diff --stat.

--numstat
    Similar to --stat, but shows number of added and deleted lines for each file, and paths without truncation.

--summary
    Output a brief summary of what happened, including creations, deletions, and modifications.

--whitespace=(nowarn|warn|fix|error|error-all)
    Define how to handle whitespace errors. Options range from ignoring (nowarn) to fixing (fix) or aborting on errors (error).

--reject
    When a patch does not apply cleanly, instead of exiting with an error, create .rej files for the rejected hunks. This allows manual conflict resolution.

--directory=<dir>
    Prepend <dir> to all file names in the patch. Useful if the patch was generated from a different subdirectory.

--verbose
    Report progress and details on stderr during the application process.

--3way
    When the patch does not apply cleanly, attempt a 3-way merge. This requires the original blob that the patch was based on to be available in the repository.

--binary
    Allows applying a diff that contains binary changes. Without this, binary diffs are treated as errors.

git-apply reads a patch in diff -u or Git diff format and applies it to the files in the working tree, or directly to the Git index. It's a lower-level command compared to git am, as it doesn't handle commit metadata, email headers, or prepare a commit message; it solely focuses on applying the textual changes.

This makes it suitable for applying simple patches downloaded from the web, or patches generated by git diff that don't need to be imported as full commits with author/committer information. git-apply is efficient and understands Git's internal diff formats, including new/old file modes, and binary diffs when explicitly handled. It provides options for stripping path components, reversing patches, and checking for apply errors without modifying files.

git-apply only applies patches; it does not automatically create commits or record the changes in the repository's history. This must be done manually with git add and git commit after a successful application. It lacks the advanced mailbox parsing and commit attribution features of git am.

For complex patch series or patches with full commit metadata (e.g., from git format-patch), git am is generally the more appropriate tool. git-apply may struggle with patches that have significant context mismatches or have been modified manually, requiring careful use of options like --3way or manual conflict resolution.

git-apply expects patches to be provided either as arguments (file paths) or piped to standard input. When multiple patch files are provided, they are applied sequentially.

By default, git-apply modifies files in the working tree. The --cached option allows applying changes directly to the Git index (staging area) without touching the working tree, which is useful for preparing a commit without local file modifications. The --index option applies to both.

git-apply has been a fundamental part of Git since its early days, serving as the core mechanism for applying diffs. Its design is influenced by the traditional Unix patch(1) utility, but it specifically understands Git's extended diff formats, including file modes, renames, and binary diffs (with the --binary option). Over time, options have been added to handle various patch scenarios, such as --3way for merge-style conflict resolution and --cached for applying directly to the index.

git diff(1), git format-patch(1), git am(1), patch(1)