What is a patch in git version control?

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!

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.