If you're talking about git config --global gpg.format ssh && git config --global user.signingKey ~/.ssh/your_key and then signing your commit with git commit --sign then yeah, in modern times it's very similar to PGP signing. There are a couple minor differences which make PGP a bit better:

1. PGP has keyservers which, in theory, allow you to upload your PGP key there, and your friends could sign it, so that others (who trust your friends through a chain of trust) know you're you. This is highly unlikely to work in practice because PGP keyservers are kinda dead and the trust network is weak (i.e. you and the person wanting to confirm it's your key are highly unlikely to have a chain of trust between you). Uploading your key to multiple keyservers at least distributes the trust a bit, compared to just uploading your ssh key to GitHub, as people can check multiple servers.
2. PGP signing allows you to store the key on a hardware key, reducing the attack surface. I don't think ssh signing allows that but I'm not 100% sure.

If you're talking about using ssh for authentication to the git server, than it's a different story. First of all, most git servers will actually accept it if you push commits committed by someone else (e.g. see this: https://github.com/jayphelps/git-blame-someone-else). (there's a tangent about Author: vs Committer: that can be had, but in any case e.g. GitHub does not do any checks on either of those fields when you push commits there). And so, someone can just "pretend to be you" and push commits somewhere as though they have been created by you. There are of course some other mechanisms around that (e.g. access control to repositories) but it's still a problem. PGP/SSH signing (as opposed to ssh authentication) is the most effective solution to that. If some commit has been signed by you, and everyone knows your public key, they can verify for themselves that you are the committer. GitHub has a way to (semi)-enforce that: if you add your GPG/SSH key as a signing key and enable "Vigilant mode" (" Flag unsigned commits as unverified "), all commits that have you as Committer which aren't signed by your signing key will get marked as "Unverified" in their web interface and raise suspicion almost immediately.

Of course this mechanism relies on GitHub (i.e. Microsoft) as the keyserver - they could in theory covertly replace your key with something else and most people would be none the wiser. Even if someone wanted to check themselves, for a project hosted on GitHub the most obvious way to find the persons PGP/SSH key is to request it from there (You can actually do that by going to https://github.com/<username>.gpg and https://github.com/<username>.ssh - e.g. here's my PGP public key: https://github.com/balsoft.gpg), so you have to trust them not to replace it. It's better than nothing but not great. If you're serious about key signing, publish your key on your own website, with as much of it controlled by you as possible (ideally on your own hardware), and advertise it widely. E.g. my key is available at https://balsoft.ru/key.

I’m am glad you asked this, because I did not know and had to look it up, so I found pgp can have multiple signatures of people saying this is a trustworthy key and helps show people it’s really you.

But if you used your regular key, how do people know it came from you ?

SSH hasn't had the signing functionality for long, and git support for SSH signatures is even younger. I'd say if you are starting from scratch, SSH signing is simpler and potentially more secure. PGP works, though, and if you have an existing setup, there is no compelling reason to change right now.

Commit signing isn't to authenticate with the remote repository. It includes the signatures in the commit data so they can be verified by anyone with a copy of the repo.

Ssh is for getting the code to the repository securely. While it is part of making sure the code doesn't change when it transit, nothing it does stays with the code after that.

PGP is for signing the code. The PGP signature is baked into the repo history itself as a part of the commit. Because it stays with the code, it provides a way to record that someone is signing off on a specific set of changes. Additionally, because it is a signature it also allows verification that the change that was signed off on has not been modified in the repository.