What is a patch in Git version control?

Question

I am new to both Git and version control so I am trying to figure out what a patch is and how is it different from the rest of activities I do in Git?

When do I apply a patch? Does it happen every time I commit?

Indication

Answer 1

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.

Abolition

A good answer, and one that tells me that a GIT 'patch' is not what I'm looking for. – Megaron

Answer 2

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!

Liddell

Never knew git uses the built in patch program. I thought git had it's own implementation. – Masry

excellent explanation! But it surprises me that the source file and the destination file are defined inside the patch-file. – Rarefied

Answer 3

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).

Transfuse

Additional info: While git does not use patches internally, one design goal for git is to make it easy to exchange patches (because many projects work that way, e.g. Linux and git itself). So git has special commands for handling patches (git diff shows changes as patches by default, git apply lets you apply a patch, etc.). – Ancell

Congratullations! You really nailed it regarding what patches are used for, that is, a means to submit changes to repositories which the author of the changes has no write access. Hence, the fork and pull request model of GitHub is a replacement for the patch model of change distribution. So I believe patches are only useful outside the context of tools like GitHub. – Dregs

Answer 4

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.

Adolescent

Better demos: robots.thoughtbot.com/…. My basic example summary: git format-patch <base_commit_or_branch_name> = wrap up all commits from now back to <base_commit_or_branch_name> into nice and neat files containing the diff as well as the commit messages, for easy sending (ex: via email) to someone else who wants to patch them to their code base. Then the recipient patches their system with your file: cat *.patch | git am – Squarerigger

Valuable answer due to the additional information on staging untracked files, as this is easy to overlook. +1 – Attentive

Answer 5

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.

Mauromaurois