GitHub pull requests: How to merge and fast-forward to avoid "recent changes" and diff notifications

Question

For my current one-man project I'm doing PRs on GitHub directly (rather than Bitbucket or Azure DevOps). I want my two branches to show they are the same after merging, but I've not found a merge option that will do that.

Merge commits and squash commits aren't in the feature branch so GitHub informs me the destination branch has "recent changes" and encourages me to make a PR to bring those into my source branch (which is where they came from).

I just switched over to the rebase option and merged a PR with four commits, but that has issues too since the commits have different SHAs. GitHub still says the destination branch has recent changes and that it's four commits ahead and four behind, and those commits cause conflicts for future PRs.

I'm curious if this is unavoidable with GitHub merging or if there's a setting or other option I'm missing.

Answer 1

tl;dr: You (currently) can't do this on GitHub, at least not directly using the web interface. See option #3 below for the workaround.

The reason is there is no option (yet?) for a fast-forward merge on its own. GitHub does have an option for "rebase and fast-forward", this strategy always does the rebase even when it wouldn't be necessary. (Note this would be like issuing the command git rebase --no-ff.)

So what can you do? Here are some options that might make sense for you:

1. You can use the regular merge strategy which creates a merge commit, and change your definition of "the same" in the context of "I want my two branches to show they are the same after merging" to mean there is no diff instead of the commits being the same. For example, git diff A B is empty when the branches are "the same".
2. You could use "rebase and fast-forward", and then delete (or reset) the source branch! You can still diff what the source branch's tip commit was with the target branch's new commit after the merge, to make sure it's the same, but perhaps you don't actually need the old commits on that source branch anymore. Either delete it and re-create it with the same name if you like that branch name, or just reset it to the new commit and force push it next time.
3. Apparently, on GitHub, you can do a fast-forward merge from the command line and push it out, and still bypass branch protection if a PR for that same merge exists, and if all the PR status checks have passed. More info here.