I work on a number of GitHub hosted projects where all changes to the default branch (typically master) are accompanied by a pull request (e.g. ol3). Typically, the pull request serves as a place where changes get reviewed and eventually approved by other contributors. But we also use pull requests for “trivial” changes that don’t typically get reviewed. A conversation came up at work about this topic, and I thought I’d share my thoughts. This is specific to GitHub’s handling of pull requests, but may be relevant to other hosted services as well.

GitHub provides a way for people to get notification about pull requests. The same is not true for merges or other commits. So opening pull requests, even if it means merging without review, allows people to keep up without reading all the commit logs.

Similarly, if you never merge into the default branch without a pull request, the GitHub API provides a fairly easy way to generate a simple change log. I say fairly easy because while the API doesn’t let you filter merged pull requests by date, you can filter closed issues by date. The full git log often provides more detail than you want, but the list of closed issues can be an effective summary of activity.

On top of that, a pull request provides a single place where all comments associated with any commits in a merge are collected. You don’t have to comment directly on the pull request, just on individual commits. If a set of changes ever needs to be revisited, the pull request is a good place to return to for a transcript of the discussion.