You couldn’t merge changes from multiple people otherwise.
Signed commits do fix this although you have to be careful about your threat model. Lots of software (e.g. gitlab) will prevent alice from pretending to be bob but will not protect you against server compromise (because public key directory and signing enforcement are done on the server).
Working at an org which does signed commits, it doesn’t buy us quite as much as we would like.
Also, if you enforce signing you can’t mash a server-side “merge” button anymore because that commit would need to be signed...
This complicates the pr/mr workflow for teams and increases resistance from those who don’t see the value in signing.
Maybe my org is just simple but if “John Doe” started submitting pull requests and prepend merged them, it’s me on the hook and there are people interested in who John Doe is. And in my org, even John Doe needs a network credential so even their local git instance (which I’ve never seen anyone use) would need a credential.
Which is why it's important for the security team to directly manage and be responsible for the code repository server. Usually the server also stores all the git repositories in some filesystem directory, meaning that server compromise would allow an attacker to remove all the company's code, regardless of permissions set for those repositories, and potentially leak it.
It seems like if an organization is allowing randos to push changes, they would also allow randos with valid pgp to push changes as well. So the investigation would change to “Who the fudge is B8956DBFEE7C105C?” instead of “Who the fudge is Bob Goodguy?”