How to do a fast-forward merge on GitHub?

Question

So one of my colleagues attempted to merge a branch using GitHub's "merge via fast-forward" option in the web-interface, to keep the history clean from bogus merge commits (the master branch into which they merged, had not progressed since the to-be merged feature-branch was started).

Funnily enough, this didn't work as expected: all the commits got new commit-hashes.

On closer inspection, it seems that merge-option is actually called "Rebase and Merge" and it really seems to do the equivalent of git rebase --force, changing the Committer information (both the person who did the merge, and the time when the merge happened).

It took me quite a while to confirm my suspicion that this is indeed the case, as I couldn't make the cmdline tools to show me the difference between the original commits on the feature branch and the seemingly-identical commits (with different hashes) on the master branch. (In the end, I found that gitk shows both Committer and Author of a commit; in the very end I found that I can also get this information via git log --pretty=raw)

So:

• Is there a way to do a "proper" fast-forward merge (git rebase without the --force option) via GitHub's web-interface?
• If not: why? (I can see merits in accountability; e.g. it answers the question who is responsible that a given piece of code ended up in master)

Answer 1

Looks like GitHub does not support this – and this is a TERRIBLE affair. You basically CANNOT run an atomic, linear commit strategy (the best there is) using the GitHub UI.

Note that Bitbucket DOES support this, and has much more fine-grained options for setting up the PR landing/integration strategy. Namely the 'Rebase, fast-forward' option which does a --ff-only update of the target/mainline branch. It also has a 'Rebase, merge' option which lets you run a rebase on target (so that your commits are linear) but integrates using a merge commit (if you want to track that the commits are all part of one logical unit/PR).

Both of these options seem superior to GitHub's limited options of either using non-linear merge commits (GitHub's 'Merge pull request' option) or linear rebase ('Rebase and merge' option), which does achieve linearity but creates duplicate commits on the source branch, thus always requiring manual Hard Resets locally if you want to keep things clean and in sync.

So... time to switch your repo provider it seems!

Answer 2

Based on GitHub's documentation and my own testing, it is not possible to do a fast-forward with the same commit hash.

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit. For more information about git rebase, see the "Git rebase" chapter from the Pro Git book.

https://docs.github.com/en/github/administering-a-repository/about-merge-methods-on-github