All commits that have been pushed to the develop branch indicate that they were verified.
To merge everything from develop to master, I decided to click a button Rebase and merge. (I didn't want to create another new commit for the master.)
Surprisingly after the merge succeeds, all the verified signatures were gone from the master.
When rebasing the changes are replayed on master. This causes them to be "rebased" on a new parent commit which will change the commit-id (which is partially based on the parent commit-id).
Rebasing may also require merging the changes as the commits are replayed. Even if the merge happens automatically, it may change the contents of the files. The file contents are another element that make up the commit-id.
The verification is done through a cryptographic signature of the contents and the commit-metadata. Hence, rebasing will break that signature.
To not break your signature you'll need to use a fast-forward merge (where no new merge commit is created). To achieve that you'll need to locally rebase your changes and sign them.
Or you can squash-rebase, where all your small commits are rolled up into a single new commit, which GitHub will sign on your behalf.
If verification is important to you, rebasing is generally a bad idea, fast-forward merges and merge commits will better reflect what actually happened and who had authored those changes.
