@phildini In the abstract, assuming no need for deniability, having it is better than not having it, but as with most things it comes down to your threat model. If you don't trust your Git repository host to not tamper with things, then it's useful. If you only sign with touch-activated Yubikeys and validate it before deploys, it could be useful. If you sign with the same SSH keys you auth to GitHub with, and you trust GitHub and have your accounts there locked down, it doesn't get you much.
@aschmitz @phildini signing only verifies information about the committer, not the author, so there is still a high degree of trust involved regarding the authorship of code. it gives you confirmation that the person who git says committed the code was the actual committer, meaning it can work in tandem with other processes you have for committers like verifying authenticity of commits and ensuring licensing rights. if you don’t have defined processes for committers, then a provenance chain that goes back to them (and stops there) does not get you much in my experience