How can we get GitHub to support fast-forward-only merges for PRs?

https://github.com/orgs/community/discussions/4618

by spir • 3 years ago

4 5 3 years ago

spir3• 3 years ago

GitHub is nearly 15 years old, and there is still no way for a pull request merge to be fast-forward-only (linear history) AND preserve the same commits as pull request source branch.

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?

junon2• 3 years ago

You seem to misunderstand a few Git things, as this feature has been available for a long time.

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.

spir3• 3 years ago

Pardon me, but I believe you misunderstand how GitHub has implemented "Rebase and Merge". In this case, github will generate new commit IDs even when the rebase is a no-op.

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.

How can we get GitHub to support fast-forward-only merges for PRs?

Related Stories