Apply Git Patches Safely with Checks, Index Control and Rollback

You will inspect a patch, check whether it applies, apply it to the intended Git state, and verify the result without accidentally committing or overwriting unrelated work. The examples describe Git 2.43.0 from Ubuntu package git-man 1:2.43.0-1ubuntu7.3, installed on the reference machine. Allow about fifteen minutes for a small patch and a little longer if you need to investigate a mismatch.

You need a shell and a readable patch file. A Git repository is needed for index operations, but ordinary git apply can patch files outside a repository. Applying a patch changes files or the index, so keep a copy of the patch and check the working tree before you begin. Do not use elevated privileges unless the target files are genuinely inaccessible to your normal account.

1. Check the command and the repository state

Confirm the installed version and move to the repository that should receive the patch:

$ git --version
git version 2.43.0
$ cd /path/to/repository
$ git status --short

An empty status output means there are no reported changes. If you see existing modifications, do not assume the patch will leave them alone. Save or review that work first, because a patch can touch the same lines and a later rollback may not know which changes were yours.

Checkpoint: identify the patch you are about to read. Treat a patch received from elsewhere as input, not as a trusted description of its effect. Review its paths and content before applying it:

$ git apply --stat /path/to/change.patch
 path/to/file.c | 3 +++
 1 file changed, 3 insertions(+)
$ git apply --summary /path/to/change.patch

--stat and --summary report information and do not apply the patch. The summary is useful for spotting new files, renames and mode changes that are easy to miss in a long diff.

2. Check the patch without changing anything

Run the dry check before the real operation:

$ git apply --check /path/to/change.patch
$ printf 'check status: %s\n' "$?"
check status: 0

A zero status means the patch passed this applicability check. There is no success message to parse. A non-zero status leaves the normal application undone, but read the diagnostic rather than immediately adding options. Common causes include the wrong directory, changed surrounding lines, a patch already applied, or a path prefix that does not match this checkout.

Git expects at least one line of context in a unified diff. If a tool generated a context-free patch, --unidiff-zero can bypass that safety check, but it removes useful protection against applying a change at the wrong location. Prefer regenerating the patch with context when you can.

3. Apply to the working tree

Once the check passes, apply the patch in the repository root:

$ git apply /path/to/change.patch
$ git diff --check
$ git diff --stat
 path/to/file.c | 3 +++
 1 file changed, 3 insertions(+)

Without --index or --cached, Git changes files in the working tree and does not update the index. It also does not create a commit. git diff --check is a useful follow-up for whitespace errors, while git diff lets you review the actual result.

The default path prefix handling removes one leading component. Thus a usual a/src/file.c and b/src/file.c patch targets src/file.c; that is the default -p1 behaviour. If the paths do not line up, inspect the patch and try an explicit value such as -p0 or -p2 only when the path structure justifies it.

4. Choose index behaviour deliberately

Use --cached when the patch should update only the index:

$ git apply --check --cached /path/to/change.patch
$ git apply --cached /path/to/change.patch
$ git diff --cached --stat
 path/to/file.c | 3 +++
 1 file changed, 3 insertions(+)

The working copy is untouched by this mode. Review the staged result with git diff --cached. This is useful when you want the patch staged for a later review or commit, but it is still a state change, so check the target path before running it.

Use --index when both the working tree and index must receive the patch:

$ git apply --check --index /path/to/change.patch
$ git apply --index /path/to/change.patch
$ git diff --cached --stat
$ git diff --stat

This stricter mode requires the index entry and working-tree copy for relevant paths to match, including metadata such as the file mode. A clean-looking patch can still fail here if those two Git states already differ. Resolve that existing difference first rather than weakening the check by habit.

5. Handle paths, whitespace and partial failures

If a patch was made from another directory layout, --directory=/path/to/root prepends a root after path components have been stripped. Prefer an explicit directory and prefix over changing into an unrelated location. Git rejects paths outside the working area by default. --unsafe-paths overrides that protection only for non-index patching and should be treated as a security-sensitive exception, not a routine fix.

Whitespace warnings are normally reported while the patch is applied. Choose the policy that matches the change review:

$ git apply --check --whitespace=error /path/to/change.patch
$ git apply --whitespace=fix /path/to/change.patch

The first command refuses newly introduced whitespace errors. The second applies the patch while fixing detected errors on changed lines. Review the resulting diff afterwards, because automatic fixing is itself a content change.

Git normally treats a patch as one operation: if a hunk cannot apply, it fails without changing the working tree. --reject changes that boundary by applying hunks that do work and writing failed hunks to *.rej files. Use it only when you are prepared to inspect and resolve every rejected file. Do not leave rejected files beside source code as if the patch were complete.

6. Verify or undo the result

Review both possible destinations after applying:

$ git diff -- path/to/file.c
$ git diff --cached -- path/to/file.c
$ git status --short

If the exact patch was applied and no other changes have been made since, reverse it with the same path options:

$ git apply --check -R /path/to/change.patch
$ git apply -R /path/to/change.patch

Do not use reverse application as a general undo button after manual edits or after another patch has touched the same lines. It can remove the wrong content or fail because the context has changed. For a repository with unrelated work, stop and recover from a known commit, backup or reviewable patch instead. There is no undo step for a patch that has already been committed; use the repository's normal review and revert workflow.