Today, if you want to preserve commits in your development branch (and not squash them; squashing is great sometimes), you have two bad options:
1. merge commits. This is bad because linear history is an excellent risk reduction mechanism for a production build.
2. rebase commits. These would be ok, except when github rebases the commits into linear history, the commit hashes change (they are new commits) even though the patch and metadata are identical. So your development branch itself constantly needs to be rebased on your production branch, because the commits being added to production are newly created by github rebase & merge.
What we need is a fourth option "Fast-forward merge", which requires linear history and only preserves (ie copies) commits from the PR source branch into the target branch.
How can we get GitHub to care about this and action on it?
First, enable "Always suggest updating pull request branches". This improves DX.
Then add a branch protection rule for the main branch with "Require linear history". This requires that PRs would otherwise fast forward.
Then disable everything but rebases. Rebases where the history doesn't need to be changed are fast-forwards. In fact, as far as I know, `--ff` isn't anything special other than "fail with an error if a rebase isn't just a fast-forward". There's no special functionality.
As far as I know, it's impossible to merge a GitHub pull request without one of squashing, generating a merge commit, or rewriting the commits. It is not possible to simply copy pre-existing commit IDs.
You can test this yourself. Simply checkout the main branch, add two new commits, push those commits to a dev branch, and try to merge them in a PR to main in a Rebase: you will observe that github has rewritten the commit IDs vs. the ones you generated locally on commit.
