1285

Say I have uncommitted changes in my working directory. How can I make a patch from those without having to create a commit?

HelloWorld101
  • 3,878
  • 2
  • 34
  • 47
vrish88
  • 20,047
  • 8
  • 38
  • 56

8 Answers8

2559

If you haven't yet commited the changes, then:

git diff > mypatch.patch

But sometimes it happens that part of the stuff you're doing are new files that are untracked and won't be in your git diff output. So, one way to do a patch is to stage everything for a new commit (git add each file, or just git add .) but don't do the commit, and then:

git diff --cached > mypatch.patch

Add the 'binary' option if you want to add binary files to the patch (e.g. mp3 files):

git diff --cached --binary > mypatch.patch

You can later apply the patch:

git apply mypatch.patch
jcarballo
  • 27,395
  • 3
  • 28
  • 28
  • 7
    I did exactly that and got "fatal: unrecognized input" upon executing git apply. Any idea what can cause this and how to fix it? – Vitaly Dec 22 '13 at 20:11
  • 11
    @Vitaly: is your patch readable if you open it with a text editor? it should be clean with no strange characters, for example if the color.diff setting is set your patch will have some 'color characters' that can make 'git apply' fail, in that case try `git diff --no-color`. Otherwise, it looks like an encoding problem. – jcarballo Dec 22 '13 at 21:06
  • 1
    Yes, it looks perfectly fine. I wasn't able to do this from the command line, but WebStorm's create/apply patch function did the trick. You are probably right about encoding issue, as I was creating a patch in Windows and applying it in Mac OS. Thanks for your reply. – Vitaly Dec 23 '13 at 00:03
  • @Vitaly: It's probably caused by UTF BOM - I had to remove the BOM bytes in editor. – Buthrakaur Mar 27 '15 at 13:46
  • 10
    To create the patch from the already staged changes you could also do `git diff --staged > mypatch.patch`, because `--staged` is a synonym for `--cached`. I think it easier to remember. – matthaeus Mar 03 '17 at 16:52
  • 4
    Related to "new files that are untracked": "git diff" and "git diff --cached" only work if "git add " has been called first. (I am new to git and wondered why I got an empty patch everytime) – Anonymous Apr 25 '17 at 08:41
  • 1
    Yeah, when I say to "stage everything for a new commit", I mean `git add` whatever you want to stage. Git therminology :) – jcarballo Apr 25 '17 at 19:36
  • 5
    This got me out of a strange merge/rebase hell pretty easily, thanks :) – John Hunt Aug 31 '17 at 10:34
  • 1
    In case you did commit it already you can diff between two commits. For example, if the fix is my last commit: ```git diff HEAD~1 HEAD > mypatch.patch``` Then to apply it anywhere else: ```git apply mypatch.patch``` – Roei Bahumi Jan 09 '18 at 08:01
  • 1
    Thank you. One the team members in my team didn't have git write only access. I wanted to check in code on his behalf patch has helped complete this activity. – arif.khan.b Jun 12 '18 at 07:42
  • 1
    would be more helpful if you add into answer how to make patch from range of commits. – Eugen Konkov Sep 13 '18 at 12:55
  • 1
    An update on this answer: if you have new untracked files you can do `git add -N ` it won't actually add the files but will start tracking them instead, making them available for `git diff` and the patch. – Ale Zalazar Apr 21 '21 at 14:58
  • 1
    `fatal: unrecognized input` is probably related to encoding issues (when using Powershell). Try to use `cmd` or `git-bash` instead of `powershell` – mihca Aug 31 '21 at 11:06
580

git diff for unstaged changes.

git diff --cached for staged changes.

git diff HEAD for both staged and unstaged changes.

sigjuice
  • 28,661
  • 12
  • 68
  • 93
  • Is the output of `git diff` enough to create a patch that can be applied with `git apply`? – vrish88 Mar 01 '11 at 19:17
  • 21
    yup, git diff is the inverse of git apply – Spike Gronim Mar 01 '11 at 19:20
  • 1
    That fails with "No such file or directory" if you have new files in new directories – Geoffrey De Smet Jul 26 '11 at 09:43
  • 41
    `git format-patch` also includes binary diffs and some meta info. Actually that would be the best bet for creating a patch, but afaik this does only work for checked in sources/ changes, right? – Eric Mar 18 '12 at 12:24
  • 1
    @sigjuice: Does git-diff handle binary differences? I think Eric has a good point, so this answer isn't quite complete. – Merlyn Morgan-Graham Mar 25 '12 at 01:21
  • 27
    Sometimes it might be useful to create a patch relative to the current directory. To achieve this, use `git diff --relative` – ejboy Jan 08 '13 at 14:03
  • 38
    git diff > a.patch to write it to a file – qasimzee Feb 12 '13 at 11:33
  • Better than `git diff --relative` is just `git diff .` (where the dot implies the diff from the current directory). – jcarballo Oct 05 '13 at 21:01
  • 152
    Terse bordering on sarcastic, the answer below is more helpful. – Air Dec 07 '13 at 19:03
  • @ejboy While very useful `git diff --relative > x` I could not use the output for `git apply x`. It just happened nothing. Strange. – towi Nov 11 '16 at 09:38
  • 6
    This is not very helpful. `git diff` does not create a patch, it merely shows the changes. Below answer actually answers the question. – aaron-coding Feb 06 '17 at 20:59
  • I have a question: can the patch generated by this `git diff` command be used by the `patch` command? Are they compatible with each other? – Rakshith Ravi Sep 04 '19 at 07:59
  • ...and `git diff HEAD` for both staged and unstaged. - i suggest you to append it to the answer – whyer Jul 23 '20 at 11:01
105

git diff and git apply will work for text files, but won't work for binary files.

You can easily create a full binary patch, but you will have to create a temporary commit. Once you've made your temporary commit(s), you can create the patch with:

git format-patch <options...>

After you've made the patch, run this command:

git reset --mixed <SHA of commit *before* your working-changes commit(s)>

This will roll back your temporary commit(s). The final result leaves your working copy (intentionally) dirty with the same changes you originally had.

On the receiving side, you can use the same trick to apply the changes to the working copy, without having the commit history. Simply apply the patch(es), and git reset --mixed <SHA of commit *before* the patches>.

Note that you might have to be well-synced for this whole option to work. I've seen some errors when applying patches when the person making them hadn't pulled down as many changes as I had. There are probably ways to get it to work, but I haven't looked far into it.

Here's how to create the same patches in Tortoise Git (not that I recommend using that tool):

  1. Commit your working changes
  2. Right click the branch root directory and click Tortoise Git -> Create Patch Serial
    1. Choose whichever range makes sense (Since: FETCH_HEAD will work if you're well-synced)
    2. Create the patch(es)
  3. Right click the branch root directory and click Tortise Git -> Show Log
  4. Right click the commit before your temporary commit(s), and click reset "<branch>" to this...
  5. Select the Mixed option

And how to apply them:

  1. Right click the branch root directory and click Tortoise Git -> Apply Patch Serial
  2. Select the correct patch(es) and apply them
  3. Right click the branch root directory and click Tortise Git -> Show Log
  4. Right click the commit before the patch's commit(s), and click reset "<branch>" to this...
  5. Select the Mixed option
Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
  • 6
    Technically this does require creating a commit which OP asked to avoid, but it's a temporary one and the answer is useful regardless. – davenpcj Jan 24 '14 at 21:25
53

To create a patch with both modified & new files (staged) you can run:

git diff HEAD > file_name.patch
Ionel Sirbu
  • 547
  • 4
  • 3
  • 1
    Thanks, in my case, this answer works, but `git diff --cached > mypatch.patch` is not working. – mining Sep 23 '16 at 06:12
  • I have a question: can `file_name.patch` be used by the `patch` command? Are they compatible with each other? – Rakshith Ravi Sep 04 '19 at 07:58
  • 1
    git diff + git diff --cached/staged == git diff HEAD (show all the changes since the last commit) – K. Symbol Feb 12 '20 at 05:17
  • 1
    @RakshithRavi afaik, yes they are. you may use your patch created by `git diff HEAD > file-name.patch` e.g. as follows: `patch --forward --strip=1 < file-name.patch` – whyer Jul 23 '20 at 19:19
32

I like: 

git format-patch HEAD~<N>

where <N> is number of last commits to save as patches.

The details how to use the command are in the DOC

UPD
Here you can find how to apply them then.

UPD For those who did not get the idea of format-patch
Add alias:

git config --global alias.make-patch '!bash -c "cd ${GIT_PREFIX};git add .;git commit -m ''uncommited''; git format-patch HEAD~1; git reset HEAD~1"'

Then at any directory of your project repository run:

git make-patch

This command will create 0001-uncommited.patch at your current directory. Patch will contain all the changes and untracked files that are visible to next command:

git status .
Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158
10

If you want to do binary, give a --binary option when you run git diff.

Sébastien Le Callonnec
  • 26,254
  • 8
  • 67
  • 80
gitster
  • 137
  • 1
  • 2
5

We could also specify the files, to include just the files with relative changes, particularly when they span multiple directories e.x.

git diff ~/path1/file1.ext ~/path2/file2.ext...fileN.ext > ~/whatever_path/whatever_name.patch

I found this to be not specified in the answers or comments, which are all relevant and correct, so chose to add it. Explicit is better than implicit!

Anshu Kumar
  • 606
  • 6
  • 18
0

uncomminetted

git diff --cached > name.patch

committed (much more useful)

git diff HEAD~commit_count > name.patch
Samet ÖZTOPRAK
  • 3,112
  • 3
  • 32
  • 33