Update (April 2021):
See "Flag unsigned commits with vigilant mode":
To improve security and confidence in the authenticity of your contributions, you can flag commits and tags on GitHub.com that are attributed to you but not signed by you.
With vigilant mode enabled (now available in beta), unsigned commits attributed to you are flagged with an Unverified badge.
This can alert you and others to potential issues with authenticity.
The author and committer of a Git commit can easily be spoofed.
For example, someone can push a commit that claims to be from you, but isn’t. >
Like showing a passport, committers can increase trust in their commits by signing them with a GPG or S/MIME key.
And now, when you enable vigilant mode, commits will be flagged if they’re attributed to you but not signed by you.
This raises attention if someone tries to spoof your identity as a committer or author. With vigilant mode enabled, all of your commits and tags are marked with one of three verification statuses: Verified, Partially verified, or Unverified.

Try it yourself!
First, check out how to automatically sign your commits.
Then, enable vigilant mode in your account settings:

Be sure to enable vigilant mode after you start signing your commits and tags.
Once you enable it, any unsigned commits or tags that you push to GitHub.com will be marked "Unverified," including past commits.
Learn more about vigilant mode.
Update (April 2016)
See "GitHub GPG signature verification":
starting today GitHub will show you when commits and tags are signed.

When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor's GPG keys uploaded to GitHub.
You can upload your GPG keys by visiting the keys settings page.

Original answer (June 2014)
From your edit, you went with option 2 in the paper "A Git Horror Story: Repository Integrity With Signed Commits":
Option #2 is as simple as passing the -S
argument to git merge
.
If the merge is a fast-forward (that is, all commits can simply be applied atop of HEAD without any need for merging), then you would need to use the --no-ff
option to force a merge commit.
Then making a signed request-pull (which can be always signed if commit.gpgsign
is set) can limit the signing part to the commits that will be merged as contribution-commits only (as opposed to any random merge between two branches).
More details on that process on:
So if your continuous integration build only merges request-pull (used in this test script), you can check if those specific commits are signed (and don't merge them if they are not).
This script is an example of such a check: "check-commit-signature
".