Search code examples
gitazure-devopsgit-mergegit-commitpull-request

Confused with pull request for dev back into master, listing merged commit again and again

I use Azure Dev Ops and have a master branch and a very fresh dev branch that had master as "parent".

Master has a policy that it can only be changed by pull requests.

When I make some changes in the dev branch, commit and push them I want those changes also "going back" into the master branch.

So I start a pull request for dev to master. There are no conflicts and I can complete the pull request/merge.

So, all is fine? But when I create a new pull request right away, again from dev to master, it lists me again the previous commit from dev. Shouldn't it (git/Azure Dev Ops) know, that this git has already been merged into master?

I thought I was being clever and now merged master into dev, thinking that this is maybe needed that dev is up-to-date (knowing the latest merge of the dev-commit into master - yes, I realize this is very likely silly). Then pushing this merge and checking in Azure Dev Ops. But now dev is ahead 2 commits and when I start a new pull request from dev to master, it now lists me the two commits as part of the new pull request. The first commit (which is already in master and the merge commit (master to dev). enter image description here

So, I am now a bit confused and I believe I have never noticed this before. I thought that normally git knows, that commits have been already merged by a pull request and don't list them again and again. enter image description here

Is there something wrong maybe with the master branch and if yes, how could I fix this?

Solution

  • More details of merge strategy you can refer to the following blog:

    https://devblogs.microsoft.com/devops/pull-requests-with-rebase/

    Squashing will take the tree that’s produced in a merge and creates a single new commit with those repository contents. It emulates running git merge pr --squash from the master branch. The resulting commit is not a merge commit; those individual commits that made up the pull request are discarded.

    When this strategy is used, history is reminiscent of a centralized version control system. Each pull request becomes a single commit in master, and there are no merges, just a simple, straight, linear history.