Skip to content

Instantly share code, notes, and snippets.

@mz0
Created February 23, 2026 10:42
Show Gist options
  • Select an option

  • Save mz0/e5f1f146b9799146fc854066a07262ee to your computer and use it in GitHub Desktop.

Select an option

Save mz0/e5f1f146b9799146fc854066a07262ee to your computer and use it in GitHub Desktop.
how to convince GitHub to NOT mess up git history

Q: my PR can merge into main --ff-only , and only "Rebase and merge" option is available in PR. When applied, the PR is merged with commit SHA different from the one in the PR HEAD. But why!? Gitlab never surprised me in that case.

A: Google AI Overview:

Even if your Pull Request (PR) branch is up-to-date with main (making it eligible for a fast-forward merge), selecting "Rebase and merge" on GitHub will always produce new commit SHA hashes, changing them from your original HEAD.

GitHub’s "Rebase and Merge" deviates slightly from a standard local git rebase:

  • New Commits: GitHub creates new commits (new SHAs) rather than just moving the existing ones.
  • Committer/Timestamp Update: GitHub updates the committer information and timestamp to when the merge occurred, rather than using the original commit date.
  • Signature Loss: Because GitHub creates a new commit, any GPG signatures from your local branch are lost.

If you need the SHA to remain the same (for example, if you tag releases by SHA), you should use merge strategy that does not rewrite history.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment