Designed as a peer-to-peer version control system, Git allows development work to be transferred directly and immediately from one repository to another using both a push and a pull model.
Git implements its own transfer protocol to exchange data between repositories. For efficiency (to save time and space), Git’s transfer protocol performs a small handshake, determines what commits in the source repository are missing from the target, and finally transfers a binary, compressed form of the commits. The receiving repository incorporates the new commits into its local history, augments its commit graph, and updates its branches and tags as needed.
Chapter 11 mentioned that HTTP can also be used to exchange development between repositories. HTTP is not nearly as efficient as Git’s native protocol, but it is just as capable of moving commits to and fro. Both protocols ensure that a transferred commit remains identical in both source and destination repositories.
However, the Git native and HTTP protocols aren’t the only mechanisms for exchanging commits and keeping distributed repositories synchronized. In fact, there are times when using the protocols is infeasible. Drawing on tried-and-true methods from an earlier Unix development era, Git also supports a “patch and apply” operation, where the data exchange typically occurs via email.
Git implements three specific commands to facilitate the exchange of a patch:
git format-patch generates a patch in email form.
git send-email sends a Git patch through an SMTP feed.
git am applies a patch found in an email message.
The basic use scenario is fairly simple. You and one or more other developers start with a clone of a common repository and begin collaborative development. You do some work, make a few commits to your copy of the repository, and eventually decide it’s time to convey your changes to your partners. You choose the commits you would like to share and choose with whom to share the work. Since the patches are sent via email, each intended recipient can elect to apply none, some, or all of the patches.
This chapter explains when you might want to use patches and demonstrates how to generate, send, and (if you’re a recipient) apply a patch.
Although the Git protocol is much more efficient, there are at least two compelling reasons to undertake the extra effort required by patches (one is technical and the other is sociological).
In some situations, neither the Git native protocol nor the HTTP protocol can be used to exchange data between repositories in either a push or a pull direction or both.
For example, a corporate firewall may forbid opening a connection to an external server using Git’s protocol or port. Additionally, SSH may not be an option. Moreover, even if HTTP is permitted, which is common, you could download repositories and fetch updates but not be able to push changes back out. In situations like this, email is the perfect medium for communicating patches.
One of the great advantages of the peer-to-peer development model is collaboration. Patches, especially those sent to a public mailing list, are a means of openly distributing proposed changes for peer review.
Prior to permanently applying the patches to a repository, other developers can discuss, critique, rework, test, and either approve or veto posted patches. Since the patches represent precise changes, acceptable patches can be directly applied to a repository.
Even if your development environment allows you the convenience of a direct push or pull exchange, you may still want to employ a “patch email review apply” paradigm to gain the benefits of peer review.
You might even consider a project development policy whereby each developer’s changes must be peer-reviewed as patches on a mail list prior to directly merging them using git pull or git push. All the benefits of peer review together with the ease of pulling changes directly!
And there are still other reasons to use patches.
In much the same way that you might cherry-pick a commit from one of your own branches and apply it to another branch, using patches allows you to selectively choose commits from another developer’s repository without having to fully fetch and merge everything from him.
Of course, you could ask the other developer to place the desired few commits on a separate branch and then fetch and merge that branch alone, or you could fetch his whole repository and cherry-pick the desired commits out of the tracking branches. But you might have some reason for not wanting to fetch the repository, too.
If you want an occasional or explicit commit—say, an individual bug fix or a particular feature—applying the attendant patch may be the most direct way to get that specific improvement.