1

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?

Patric
  • 2,789
  • 9
  • 33
  • 60
  • 1
    Did you rebase or squash in that previous pull request? – Lasse V. Karlsen Dec 01 '20 at 22:41
  • In the previous (first) pull request I squashed. – Patric Dec 01 '20 at 23:03
  • 1
    So then that is why. Git look at the commits when it shows merge content, not the contents of those commits. As far as git is concerned, that particular commit was not merged. The contents of it was, but not that commit. So that's why it now shows up as unmerged. – Lasse V. Karlsen Dec 01 '20 at 23:15
  • 1
    Git does not track which commits went into a squash. When you squash, you construct one or more new commits which are completely separate from the original ones. If you still have a way to reference the original ones, they will then be counted as "not merged". – Lasse V. Karlsen Dec 01 '20 at 23:16
  • ah I see. We recently changed our git workflow a bit, I believe mayb that's why I never noticed this before. So that means, if I don't want this to happend I should not squash the pull request but rather rebase with fast-forward? – Patric Dec 02 '20 at 07:59
  • Or, after you squash one PR, you should rebase the parts of the other PR based on top of the old branch onto the new squashed commit. – Lasse V. Karlsen Dec 02 '20 at 08:02
  • Rebasing will have the same problem. If you squash and/or rebase the first PR, you will have this scenario popping up in subsequent PR's based on top of the first branch. – Lasse V. Karlsen Dec 02 '20 at 08:03
  • ok, I notice that I must read more about rebasing/squashing, I am not currently able to fully understand your last two comments. Btw, you should pack your comments into an answer. – Patric Dec 02 '20 at 08:05
  • One thing I forgot to mention, what initially led me also to fiddle around with this issue. I was sometimes unable to merge my pull request, because git would tell me there where merge conflicts, e.g "Readme.md - deleted in dev, edited in master", but I still not understand why. It was not edited edited in master (at least not in the last commit to master; so why doesn't it act like "ok, user has deleted file in the branch we merge into master, so I (git) will also delete it in master". – Patric Dec 02 '20 at 08:23
  • The important part is whether it was changed on master *since you created your branch*. Git doesn't merge snapshots, it merges changes, so all the changes since branch creation, on both branches, are considered. – Lasse V. Karlsen Dec 02 '20 at 12:44

1 Answers1

0

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.

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • We used following strategy (which may be bad). We have a MASTER branch and a DEV branch. We work all changes on the DEV branch and should regularly commit and push those changes back into MASTER. So DEV lives not only long, it lives forever. For merging PR (from DEV) into MASTER we used "squash commit". But I belive this means, that when I create a new PR after a previous one, we will always see all the previous commits in the "New PR form". And this list will grow and grow, as DEV was branched way in the past from MASTER. Is this assumption correct and how to avoid it? Merge without squash? – Patric Dec 02 '20 at 11:15
  • 1
    Well I got it working now. I merged master back in dev to get commits that where missing in dev and used "merged" (not squashed commit) as PR merging strategy. With this my commit history is as desired and in new PRs the old commits are not present, I also don't have the issue with the conflicting files any more. – Patric Dec 02 '20 at 14:17