What is a patch in git version control?

Question

You can see in this blog post how you can create a patch (collection of changes you want to communicate and apply to another repo)

^{(picture from the 2008 blog post "Bioruby with git: how would that work?", published by Jan AERTS)}

See also Contributing to Rails with Git as another concrete example.

Nowadays, the GitHub pull request makes it really easy to apply patches on GitHub repos, which is useful when you aren't a direct contributor (ie you have no right to directly push to a repo).
Actually, fairly recently GitHub introduced "Better Pull Request Emails" to improve the notification of new patches.

Patch is a Unix program that updates text files according to instructions contained in a separate file, called a patch file.

So, in other words it may mean the file with instructions or a program that processes that file and applies it to something.

Now, what is a patch file? Let's say you have a text file with 2 lines:

This is line A.
This is line B, or otherwise #2.

Then you change the first line, and now your file looks like this:

This is SPARTA.
This is line B, or otherwise #2.

How would you describe the change to the contents of the file? You can say that first line "This is line A." got replaced with "This is SPARTA.", or even the last word "A" of the first line replaced with another word "SPARTA". And that is exactly what diff tells us. Let's say I have two versions of this file, one called file1.txt and another one file2.txt, then I run diff and get this:

$ diff -u file1.txt file2.txt 
--- file1.txt   2011-11-26 11:07:03.131010360 -0500
+++ file2.txt   2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
 This is line B, or otherwise #2.

Having a description of changes, you can apply it to a initial content and get a modified content. And those changes, put in unified format that "patch"-like programs can understand, is called a patch file. It's like instead of getting a fish from someone they teach you how to fish, so that you can dig that fish out of the waters yourself. Now, let's apply our patch to file1.txt to make it look exactly like file2.txt:

$ cat file1.txt 
This is line A.
This is line B, or otherwise #2.
$ cat file2.txt 
This is SPARTA.
This is line B, or otherwise #2.
$ diff -u file1.txt file2.txt > changes.patch
$ cat changes.patch 
--- file1.txt   2011-11-26 11:09:38.651010370 -0500
+++ file2.txt   2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
 This is line B, or otherwise #2.
$ patch < changes.patch 
patching file file1.txt
$ cat file1.txt 
This is SPARTA.
This is line B, or otherwise #2.
$ 

You may think that it is easier to just have two versions of this file. Well, in this simple case that is true. But when you have a lot of files, and those files are very big, it is a lot more efficient to have a few lines of changes rather than two copies of the whole thing.

When talking in terms of git, patch file still means the same thing, but using diff + patch yourself would be a nightmare. For example, you will always have to have two versions of the file (or even the whole repository) checked out in order to compare them. Doesn't sound that good, does it? So git takes care of all of the hard work for you - it compares your local file with what is there in the repository you are working with, and can show it to you as a "diff", or apply that "diff" as a patch aka commit your changes, or even let you apply some patch file that you have already. Without going deep into details, in this sense git is absolutely the same as other version control systems like SVN, or even CVS or perforce.

Hope it helps!

A patch is a small file that indicates the changes made in a repository. It's generally used when someone from outside your team has read-only access but had a good code change available. He then creates a patch and sends it to you. You apply it and push it to the git repository. Everyone then benefits from the updated version, and the author of the patch didn't need read/write access.

It's really mainly a security thing (at least, that's what people use it for).

A patch file represents a single set of changes that can be applied to any branch, in any order. By using patch, you will get differences between one or more files. And later, you can apply the differences (patch) to get the changes on new files. There are many uses for a patch in Git. If you have uncommitted changes in your working directory, and you need to get that changes to apply somewhere else, just create a patch and apply the patch.

git diff > mypatch.patch

If you have new files in your repository(untracked), then you should stage the file before creating a patch (don't commit), and use the following command

git diff --cached > mypatch.patch 

You can later apply the patch:

git apply mypatch.patch

If you want to make some changes to a git repository, that you don't have a write permission, just make the changes and create a patch between both, and send the patch to someone who has the permission to apply the patch, by this your changes should be added to that git repository.

A patch is a set of differences between one or more files, to show what is different between them. You would typically only generate a patch to show someone what you have changed. An example of when you might do this is when you find and fix a bug in an open source application and then post the fix on their bug tracker.