• Servers and Tools

Pull Requests

From the class:  Git Workflow

Now I'm back in the original project as the project maintainer, so I'm Evented Labs now, and what I want to do is check what new issues have been created. I could go to the GitHub website to do that, and it's likely that I will have gotten an email to notify me that a new pull request has come in. But I could right from the command line say, Git Issue, and that will also show me all the issues in reverse chronological order, including the pull requests. So you can see the last pull request was submitted with an ID of three at the top of the list here. And let me show you a quick trick you can use on the command line.

You can type Git Issue, and then pipe that output into the head command, and that'll allow me to see just the last, say, one or two issues. Let's just say we want to see one, and this will just filter that list by one. So you can use these Bash pipe commands to kind of pipe one thing into the next thing, which is pretty useful. There's a couple of different ways that we can merge and pull requests. I'm going to show you one way for simple pull requests, and then in another video, I'll show you a more complex workflow.

In this case, I know that the pull request is very simple. It has one commit in it, and it's an update to one file. So what I'd like to do is to just apply those changes on top of the Devel branch without doing any kind of merging, and to do that, I can use the Git AM command like we saw in the merging class. I'm going to show you a quick trick on how we can get a patch from GitHub. We can take any pull request URL like this one and just add a patch extension to it.

Let me use the Curl command, and I'll get a capital L flag. That means follow any redirects, because we're actually going to get redirected here. And I'll add the .patch to the end of this URL. When I do that, GitHub will format a nice Git Diff Patch for me, and I can take this patch and apply it to the Git AM command, just like I could with a regular patch file, and we saw how that all worked in the last class.

To do that, I'm going to take the output of this curl request and pipe it into the Git AM command and use the dash to tell AM to read from standard input. When the process completes, that patch will have been applied on top of our Devel work as a new commit, and I could check it out with the Git Log command, and we'll look at the graph so that we can make sure that no merges have happened. It just went ahead and applied it right on top. There's no merge from this to the next. It just goes from this commit to the one that we just applied, which has the pull request in it.

Also note that the commit message that came from the pull request is the one that came from the diff patch, and so we got that commit message automatically. We didn't have to type one in ourselves. Now let's push up this change to the origin branch to Git Push Origin Devel so that other developers on the team will have access to this merge pull request now.

Back in the GitHub project, if I click on the Commits tab, you'll see the latest commit that was added as part of this pull request. And if you click on the link to the issue, you'll notice that it was closed automatically. That's because in the commit message, we said that it closes issue number two, and so GitHub automatically closes this for us, which is quite a nice feature.

Also, notice down here that we get another kind of status message that says that Evented Labs, the other user, pushed a commit that closed this issue five minutes ago, but the original author-- that's the CMather, my dual personality-- gets credit for the commit. So this is a nice easy way to take a patch and just apply it directly and create a new commit message automatically that keeps all the original author information and the metadata, and then we can just push up that change.

Let me show you one last trick. It's nice to have a file that has all the authors that have worked on the project. It gives some credit to people who work on it, and other people who come to the project who are new will know who the people are. To do that, there's a command that comes with Git Extras that we installed in the beginning of the class. It's called Git Authors, and when I do that, it's going to open up a Vim window with all the various authors who have worked on the project so far. I think it's in alphabetical order.

And when I save that file and quit, notice that there's a new file in the project now called Authors, and we can take a look at it. It just contains what we just saw in the Vim Editor. Let's go ahead and add this and commit the change. Add an author's file. I think this is a nice touch. Not all projects will have it, but I would recommend it. So we'll Git Push this up to Devel. Next up, we'll work on a slightly more complicated feature and a different type of pull request merge workflow.