I have used GitHub for years and there are many aspects of the service I’ve come to love. For example, per-project wikis, automatically closing issues via commit messages, the simple but straight-forward controls for managing repository access, and so on.
But there is one feature of GitHub that has always bothered me: merging pull requests. I want to explain why I don’t like the feature, why I often avoid it, and how I prefer to merge pull requests.
Problem One: Noisy, Unnecessary Commits
When you click GitHub’s button to merge a pull request it creates a commit like this, a merge commit. Inherently this is useful behavior. For example, when merging a branch that contains multiple commits—such as the commit I just referenced—I prefer to have a merge commit in the history; that commit becomes a useful target for
git revert if it turns out that a branch of patches needs to be “unplugged” at a later date.
The problem, however, is when a pull request consists of a single commit. GitHub will still create a merge commit when you merge the pull request via its interface. For a pull request containing only a single commit this creates messy noise in the repository’s history. I don’t gain anything by having a merge commit in my
master branch for the sake of integrating a single commit.
When it comes to merging a pull request containing a single commit, GitHub creates unnecessary noise.
Problem Two: Testing
Merging a pull request through GitHub does not allow me a sufficient amount of testing for the proposed changes. Services like Travis CI help a lot, but I still prefer to test pull requests locally. Here I think the convenient allure of merging a pull request with a single mouse-click degrades the quality and quantity of testing on a project. I’ll admit that this criticism is hypocritical coming from me, as I have allowed many bugs to creep into PHP Mode for Emacs.
Problem Three: Signing-Off and Other Commit Metadata
I like to sign-off on commits as an indication that I’ve personally reviewed and tested the patches in a pull request. To my knowledge this is not possible through GitHub’s UI. But I will admit that I could be wrong here, because due to the problem of testing mentioned above I’m already not using GitHub’s UI by the time I am ready to merge a pull request. So maybe there is relevant functionality here which I’ve overlooked.
There are times I also like to add lines to commit messages, such as references to relevant GitHub issues. Again, this isn’t possible from GitHub’s pull request UI as far as I know.
How I Prefer to Merge Pull Requests
When I receive a pull request it will be at a URL like this:
The first thing I do is fetch the pull request, creating a new branch for it in the process. For the above I would do this:
$ git fetch origin pull/255/head:php7-syntax $ git checkout php7-syntax
The general syntax for the fetch is
pull/$ID/head:$BRANCHNAME. This example would grab the commits for the pull request at that example URL and put them into the new branch
php7-syntax. Which I then checkout and begin to review and test.
When I’m satisfied with the pull request and am ready to merge I will do one of two things. In both cases I will start with
git checkout master.
If the pull request contains only a single commit then I will run
git cherry-pick -s $BRANCHNAME. This signs-off on the commit.
If the request contains multiple commits then I do this:
$ git merge --no-ff --no-commit $BRANCHNAME $ git commit -sv
This creates a sign-off on the merge commit, which is my personal preference for indicating I reviewed everything in the branch. And it also gives me a chance to add any important information to the merge commit if necessary.
In both cases I will end up with a different SHA-1 hash for the result than if I had used GitHub’s feature to automatically merge the pull request. Because of that I always paste that SHA-1 into a message on GitHub when I am closing the pull request. That way the author of the pull request can see that their work is merged and thus can delete their own branch if they want.
GitHub’s feature to merge pull requests does not give me the level of control that I want during a merge process. That is not to say the feature is worthless or anything. It just doesn’t fit into how I prefer to manage a repository.
If you like that feature of GitHub I would love to hear why, or if you’re like me and prefer to avoid it then I’d also love to hear about your own process for merging pull requests.