This seems to me a fundamentally bad idea: signing commits should be a "long lived" thing, but using an infrastructure designed for easily replaceable authentication (ie: add your pub keys to servers and remove/replace/destroy them at the very minimal suspicion of the private keys being compromised). And all the non-existing certification infrastructure (the article proposes one; we can end up with multiple incompatible signing/certification systems, none of them with the reach of existing OpenPGP). And at last, but not least, putting too many eggs in the same basket.

It’s better than not signing at all, though, which appears to be the current status quo.

You can also sign with a different key than your “regular” ssh key(s), and as such reduce the chance you’ll have to replace them.

Having said that, key rotation and distribution is obviously better with GPG, and I personally have been using that for years.

Commit signing with S/MIME also works great. The downside is that you have to buy an "email" S/MIME cert from one of the usual cert gatekeepers for a couple dollars, but in return anyone can verify the signatures without exchanging public keys with me (or building a web of trust), and expiration and revocation are solved problems (including verifying signatures made with keys that are now expired, which seems not really supported with SSH keys)

(disclosure: I'm a maintainer for gitsign)