I’m slightly embarrassed that I have to ask this question as I’ve been a developer for many years, but something surprised me at work today so I thought I’d clarify what is correct with the community.
I noticed that when we merge PRs into master, all previous commits added as part of that PR are added to master then a merge commit is also added.
For example, if I add a new PR with 1 single commit then merge it – I’m then seeing 2 commits on master, a single one that matches the commit in my PR then another with the exact same changes labelled as "Merge pull request #XXX".
This confused me as I thought what happened was a single merge commit was added with all of the changes from that PR included in that commit.
I’m aware you can squash and merge as well as rebase and merge, but I’m specifically talking about the default option in github when you merge a PR.
I’ve had a play around since and this looks like its just the default behaviour, but I’m sure I’ve never seen this before in my 20 years of professional development so I’m having a bit of a fuss over it.
Is this normal and I might be starting to lose my mind?
>Solution :
This confused me as I thought what happened was a single merge commit was added with all of the changes from that PR included in that commit.
This is the behavior of a squash commit that you are familiar with.
If it helps in not loosing your mind I would think of it like this. The commit on the branch has only one parent commit. All commits apart from the merge commit and the initial commit has exactly one parent commit.
When you make the commit on the branch git does not know if you are about to make more commits in the branch so it creates a regular commit with one parent commit. When you merge the two branches you need a commit that is different in that it has two parent commits. One in each branch in the merge.