The whole part of signing commits is providing proof that you are who you say you are with the same level of trust provided by other systems built using Public Key Crypto.
You need people to properly secure their keys of course, but it makes life a lot harder for an attacker.
I sign my work-based git commits. I've been using GPG since the late 90s. It's not a silver bullet (especially when a git server has been owned).
When you git pull, then do your work and git commit/push, if you are not careful and you do not examine git status/diff you could sign and commit the hackers change (that you pulled from the repo initially) along with your new changes. So care is required even with PGP signed commits.
This is another good reason to not interrupt developers while they are working. Doing so, makes mistakes such as this more likely.
Can you walk me a scenario where you and I are hosting our code on a malicious git server and Chuck can get their code in our our codebase? (assuming only signed commits)
You don't really pull down code though, you pull down commits. I'm not seeing a case where you sign the attackers code. You might sign a merge commit that has an attack commit somewhere in the tree, but that's very different and much more easily audited.
Even if we assume the git server is completely malicious, I'm still not seeing a case where an attacker can hide a change because I didn't 'status/diff'. I'm open to considering attacks I haven't thought of though.
I think the problem on GitHub is that if you compromise someone's GitHub account (from a leaked password or whatever), you can just add a new public keypair to the account, and now you can sign code as that user.
Requiring two-factor auth for the GitHub account should be good for this though.
