Why does GitHub add all commits from the feature branch to main when doing a merge commit?
From my understanding, a git merge from a feature branch to the main branch creates a new commit on main that has two ancestors (the last commit on the feature branch and the last commit on main). Only one commit that merges the changes from both branches (the merge commit) will be added to main. Am I correct here?
Opposed to that, when I merge a Pull Request an GitHub with the option "Create a merge commit", all commits from the feature breanch are being added on top of the main branch and then of top of that there is the expected merge commit. Adding all commits to main is a behavior I would expect form rebase, but I'm under the impression that I'm doing a merge commit here (which is backed by the fact that an additional merge commit is being created).
The GitHub docs are very ambiguous about the different PR merge methods. For the default merge option "Create a merge commit" it says:
[...] all commits from the feature branch are added to the base branch in a merge commit. The pull request is merged using the --no-ff option.
Which sounds very much like what it does but not like what I would expect from a git merge.
It sounds even more so, if I compare it to what the docs say about "Squash and merge":
When you select the Squash and merge option on a pull request on GitHub.com, the pull request's commits are squashed into a single commit.
I could do "Squash and Merge" instead of just merging, but the docs also warn about re-using already merged branches:
If you continue working on the head branch of a pull request after squashing and merging, and then create a new pull request between the same branches, commits that you previously squashed and merged will be listed in the new pull request.
Re-using merged branches is something I would occasionally do, so I'd prefer to go with the normal merge.
So what are my options to get expected git merge behavior on GitHub? Or do I understand something wrong here?
EDIT: @Gaël J's comment gave me the idea that GitHub still has this graphical branch view somewhere hidden in the repository's insights and according to this view, the merge commits are being done as I would expect:
But when I go into the Code view and look into the history of main, I see all those commits as if they would have been done on main. Might be another "improvement" of GitHub to adhere to some new dev style, but I find it very confusing. I also did not find any option to turn that behavior off and only see the actual commits on main if main is selected :-(
As mentioned in the comments, the behaviour you expect with merge commits is what is really happening.
This can be verified in the "graphical view".
You're being confused by the "commits list" view which shows all commits belonging to a branch without the branching paths.
Why does GitHub display like this? Because that's still the reality. A branch is just a pointer to a commit. All ancestors commits are part of the branch, no matter if at the time they've been pushed they were pushed to another branch name.
A commit belongs to a branch if it's reachable from the "head commit" of the branch (the pointer).
Edit: with Git directly, you can possibly get the view you'd like. See Showing commits made directly to a branch, ignoring merges in Git