Thus far, all of the collaboration workflows we’ve seen rely heavily on branches. For example, in the last module, a contributor had to publish an entire branch for us to merge into our project. However, it’s also possible to communicate directly on the commit level using a patch.
A patch file represents a single set of changes (i.e., a commit) that can be applied to any branch, in any order. In this sense, the patch workflow is akin to interactive rebasing, except you can easily share patches with other developers. This kind of communication lessens the importance of a project’s branch structure and gives complete control to the project maintainer (at least with regards to incorporating contributions).
Integrating on the commit level will also give us a deeper understanding of how a Git repository records project history.
DOWNLOAD THE REPOSITORIES FOR THIS MODULE
If you’ve been following along from the previous module, you already have everything you need. Otherwise, download the zipped Git repositories from the above link, uncompress them, and you’re good to go.
Learn how to use GIT, from beginner basics to advanced techniques, with online video tutorials taught by industry experts. Enroll for Free GIT Training Demo!
If you’ve set up a Bitbucket account, you should also run the following commands to configure the downloaded repositories:
cd /path/to/my-git-repo git remote add origin https://@bitbucket.org//my-git-repo.git cd ../marys-repo git remote add origin https://bitbucket.org//my-git-repo.git
Change the Pink Page (Mary)
We’ll begin by pretending to be Mary again. Mary didn’t like the pink page that John contributed and wants to change it.
cd /path/to/marys-repo git checkout -b pink-page
Developing in a new branch not only gives Mary an isolated environment, it also makes it easier to create a series of patches once she’s done editing the pink page. Find these lines in pink.html:
and change them to the following.
Stage and commit the update as normal.
Note that Mary’s local development process doesn’t change at all. Patches—like the integrator and centralized workflows—are merely a way to share changes amongst developers. It has little effect on the core Git concepts introduced in the first portion of this tutorial.
Create a Patch (Mary)
Mary can create a patch from the new commit using the git format?patch command.
git format-patch master
This creates a file called 0001-Change-pink-to-a-manly-color.patch that contains enough information to re-create the commit from the last step. The master parameter tells Git to generate patches for every commit in the current branch that’s missing from master.
Open up the patch file in a text editor. As shown by the addresses in the top of the file, it’s actually a complete email. This makes it incredibly easy to send patches to other developer. Further down, you should see the following.
This unique formatting is called a diff, because it shows the difference between two versions of a file. In our case, it tells us what happened to the pink.html file between the 98e10a1 and 828dd1a commits (your patch will contain different commit ID’s). The -7,8 +7,7 portion describes the lines affected in the respective versions of the file, and the rest of the text shows us the content that has been changed. The lines beginning with – have been deleted in the new version, and the line starting with + has been added.
While you don’t have to know the ins-and-outs of diffs to make use of patches, you do need to understand that a single patch file represents a complete commit. And, since it’s a normal file (and also an email), it’s much easier to pass around than a Git branch.
Delete the patch file for now (we’ll re-create it later).