In this repo when I open a Pull Request and merge it, GitHub is creating 2 merge commits, in the image example i solved some conflicts and merged. I haven`t done any squash or rebase on the branch alteracoesPequenas. Why is this happening?

Image of the two merge commits on git tree

CodePudding user response：

A minor correction might make this much clearer:

when I open a Pull Request and merge it, GitHub is creating 2 merge commits...

Actually, you made the first merge commit when you merged master into your branch to resolve the conflicts, and GitHub made the second merge commit when you completed the Pull request. This is a common occurrence, and nothing to worry about.

If it bothers you, you can probably avoid the first merge commit that you made. To resolve conflicts on your branch before completing a PR you can either merge in the target branch like you did, or you can rebase your branch onto the target branch. With rebase you rewrite your branch such that it appears as though you branched off of the latest master right now, and then made all of your commits on top of that. (Which, btw, is why we say you rebase "onto" master versus merging master "into" your branch.) With rebase your branch will be linear and won't have the initial merge commit.

As for the merge commit that GitHub creates when you complete the PR, this is because of the merge strategy selected, and "merge" is the default option (and perhaps the preferred option of most projects for merges into long-lived shared branches). GitHub offers 2 other options which are "squash, merge" which will squash all of the changes into a single linear commit, and also "rebase, merge"¹ which will once again rebase your branch onto master like you potentially did to resolve the conflicts. Note if you choose this option, GitHub will rebase your commits again even if your branch is already up to date with master and doesn't need it. I assume they do this to avoid confusion caused by sometimes your commit IDs change and other times they don't. Here they always will change.

So to sum this all up:

1. You can avoid the first merge commit by rebasing instead of merging to resolve conflicts.
2. You can avoid the second merge commit by selecting either the squash-merge, or rebase-merge strategies when completing your PR.

My personal preference is rebase to avoid the first merge commit, but still use merge when completing PRs to have one merge commit into master.

¹ IMHO, "rebase, merge" really ought to be called "rebase, fast-forward". Using the word merge there kind of implies a semi-linear merge which can be achieved by rebasing and then merging with --no-ff to force a merge commit. I suppose GH is using "merge" here in the default sense of fast-forward if possible, and in this case it will always be possible. This wording choice would probably be more obvious if GH offered both options, like Bitbucket does.

CodePudding user response：

What you're seeing is correct and normal. Merging makes a merge commit; that's what a merge is. So:

1. You wanted GitHub to merge alteracoesPequenas into master, closing the pull request; but GitHub wouldn't do it, because of merge conflicts.
2. So you resolved the conflicts by doing a reverse merge of master into alteracoesPequenas. (Merge commit)
3. Then you were able to have GitHub merge alteracoesPequenas into master, which was your goal. (Merge commit)

All very right and proper and completely standard. Don't worry, be happy.

NOTE Another psychological issue here may be GitHub's way of presenting what happened. This is not a topological diagram, it's just a flat list of commits reachable from master. The first merge commit you did isn't really "on" master in the sense you probably think of it; it's "on" alteracoesPequenas. Only one merge commit is "on" master, namely the merge commit that closed the pull request.