Export uncommitted Git changes as a patch

Export staged, unstaged, new, and binary files as a Git patch; check application, handle conflicts, and preserve commits with format-patch.

Best practices
Illustration of Git history and collaboration

Use git diff for unstaged changes, git diff --cached for staged changes, or git diff HEAD for the combined change relative to the current commit. Save the result as a patch and apply it in a compatible checkout with git apply.

Export the changes you need

Run these alternatives from the repository root. The output files are placed outside the working tree so they cannot accidentally become part of a later patch.

# Working tree compared with the index
git diff --binary > ../unstaged.patch

# Index compared with the current commit
git diff --cached --binary > ../staged.patch

# Combined tracked-file changes compared with the current commit
git diff HEAD --binary > ../all-changes.patch

The last command records the final content change; it does not preserve which individual edits were staged. It also requires an existing HEAD commit. --binary includes applicable binary-file changes instead of only reporting that binary contents differ.

Untracked files are excluded by default. Mark the particular new files you want with intent-to-add, then regenerate the combined patch:

git add -N -- path/to/new-file
git diff HEAD --binary > ../all-changes.patch

Review the patch before sharing it. Intent-to-add changes the index metadata without staging the file's contents. Avoid marking every new file indiscriminately, especially when a directory contains credentials or generated output. The diff and add documentation explain these comparisons and intent-to-add behavior.

Check and apply the patch

In the receiving repository, start with the expected base and inspect any existing local edits:

git status --short
git apply --stat ../all-changes.patch
git apply --check ../all-changes.patch
git apply ../all-changes.patch
git diff

The normal apply command changes the working tree without creating a commit or staging the result. After reviewing and testing, stage and commit the changes as appropriate.

To reverse an applied patch, first check that the reverse still applies to the current files:

git apply --check -R ../all-changes.patch
git apply -R ../all-changes.patch

This is not a general rollback for unrelated edits made since application.

Export an existing commit instead

For a committed change, use a mail-style patch when you want to retain its author and commit message:

git format-patch -1 HEAD --stdout > ../last-commit.patch

Apply it in the receiving checkout with git am ../last-commit.patch. This creates a commit; it need not have the same commit ID as the original. See git-format-patch and git-am.

Common questions

What if the patch does not apply? Check that the target is based on the expected revision. git apply --3way ../all-changes.patch can attempt a three-way merge if the patch identifies its base blobs and those blobs are available locally. It normally also updates the index and may leave conflicts to resolve. It cannot reconstruct a missing base from arbitrary patch text. See git-apply.

Can I include images and other binary files? Yes. Export with --binary, then verify the applied files. This does not include an untracked binary file unless you first include that file in the comparison.

Should I use a patch or a stash? A patch is convenient to inspect and transfer between compatible checkouts. A stash is useful for temporarily setting work aside in the same repository; git stash push -u can include untracked files. Plain git stash create is not a substitute for exporting those files. See git-stash.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting