Many unanswered questions.
Many unanswered questions.
https://docs.github.com/en/authentication/managing-commit-si...
https://docs.gitlab.com/ee/user/project/repository/ssh_signe...
https://developer.1password.com/docs/ssh/agent/
https://keepassxc.org/docs/KeePassXC_UserGuide.html#_ssh_age...
Although in full transparency, I still use GPG for my needs, since I better understand its workflow
All those "verified" buttons you see on a typical repo history tend to actually be for the GitHub.com signing key, which is shared by everyone. Your GPG signature is only used to convince GitHub to sign the final commit with its key.
It is possible to put your GPG signature on the merged commits, so that people can trust the commits came from you. That may be especially appropriate for security software. But you have to do the merges (or rebases as you prefer) outside GitHub for that, and push those merges directly to the main branch. That's what I do when I can, but it's not common practice. Many orgs require all merges to be done via GitHub, so end up with GitHub.com's shared signature on everything instead of their own.