On GitHub, a merge commit keeps the original commits, squash combines them into one, and rebase rewrites them. Rebase and merge creates new commits that GitHub cannot sign for you, so they arrive without signature verification. If you require signed commits, choose the method deliberately.
The three methods
According to GitHub's documentation:
- Merge commit. Adds all branch commits to the base plus one merge commit. Branch structure is preserved and original commits keep authorship.
- Squash and merge. Combines all pull request commits into one commit. Original SHAs are lost and so is information about who authored the squashed commits.
- Rebase and merge. Adds each commit separately with no merge commit. This gives linear history, but the commits are rewritten with new SHAs and updated committer information. Because GitHub cannot sign on a user's behalf, the rewritten commits have no signature verification. A workaround is to rebase locally and push to the base branch.
The page does not describe signature handling for the other two methods, so test your own setup.
Linear history
Squash and rebase both produce linear history. To block merge commits on a protected branch, require linear history. When a merge queue is used, the queue controls the merge method.
Interaction with required signing
The branch protection documentation notes that unsigned commits on the head branch can block a pull request merge, squash merges included. If you require signed commits, check how contributors sign, and where your merge method creates new commits.
Choosing
- Need signed history and author detail: merge commits keep the originals.
- Want a clean log: squash, and accept that individual author detail is merged.
- Want linear history with every commit: rebase, and accept the signature gap or rebase locally.
You can restrict a repository to one method so contributors cannot choose differently. Write the choice into your contributing guide and check it quarterly.
What signatures can and cannot tell you
A signature ties a commit to a key, not to trustworthy code. See what signed commits prove and do not prove.
Whatever you choose, write it down and test it once with a real pull request in a sandbox repository. Create a branch with signed commits, merge it each way, and look at the resulting history and badges. Five minutes of testing replaces guesswork, and the screenshots make useful evidence of how your change control works when an auditor asks how signing and review interact in your pipeline.
Try it yourself
Click through it at your own pace, or open it full screen. Check which condition lets the merge proceed.
Quick check
Why do rebased commits lose their Verified badge?
GitHub creates new commits and cannot sign on the contributor's behalf, so they have no verification.
Which methods give linear history?
Squash and rebase. Merge commits do not.
Sources
Last reviewed: 19 October 2026.
