对 dev 的 pull request 回到 master 感到困惑，一次又一次地列出合并的提交
Confused with pull request for dev back into master, listing merged commit again and again
我使用 Azure Dev Ops 并有一个 master 分支和一个非常新的 dev 分支，它以 master 作为“父级”。
Master 有一个策略，它只能通过 pull requests 来改变。
当我在 dev 分支中进行一些更改时，提交并推送它们我希望这些更改也“返回”主分支。
所以我开始向 master 发起 dev 的拉取请求。没有冲突，我可以完成拉动 request/merge.
那么，一切都好吗？但是当我立即创建一个新的拉取请求时，再次从 dev 到 master，它再次列出了我之前来自 的提交开发。它（git/Azure Dev Ops）难道不应该知道，这个 git 已经被合并到 master 中了吗？
我以为我很聪明，现在将 master 合并到 dev，认为这可能是 所需要的dev 是最新的（知道最新的 dev-commit 合并到 master - 是的，我意识到这很可能是愚蠢的）。然后推送此合并并签入 Azure Dev Ops。但是现在 dev 领先 2 次提交，当我开始从 dev 到 master 的新拉取请求时，它现在将这两个提交列为新拉取请求的一部分。第一个提交（已经在 master 中）和合并提交（master 到 dev）。
所以，我现在有点困惑，我相信我以前从来没有注意到这一点。我认为通常 git 知道，提交已经通过拉取请求合并并且不会一次又一次地列出它们。
master 分支是否有问题，如果是，我该如何解决？
更多的合并策略可以参考下面的博客：
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.
我使用 Azure Dev Ops 并有一个 master 分支和一个非常新的 dev 分支，它以 master 作为“父级”。
Master 有一个策略，它只能通过 pull requests 来改变。
当我在 dev 分支中进行一些更改时，提交并推送它们我希望这些更改也“返回”主分支。
所以我开始向 master 发起 dev 的拉取请求。没有冲突，我可以完成拉动 request/merge.
那么，一切都好吗？但是当我立即创建一个新的拉取请求时，再次从 dev 到 master，它再次列出了我之前来自 的提交开发。它（git/Azure Dev Ops）难道不应该知道，这个 git 已经被合并到 master 中了吗？
我以为我很聪明，现在将 master 合并到 dev，认为这可能是 所需要的dev 是最新的（知道最新的 dev-commit 合并到 master - 是的，我意识到这很可能是愚蠢的）。然后推送此合并并签入 Azure Dev Ops。但是现在 dev 领先 2 次提交，当我开始从 dev 到 master 的新拉取请求时，它现在将这两个提交列为新拉取请求的一部分。第一个提交（已经在 master 中）和合并提交（master 到 dev）。
所以，我现在有点困惑，我相信我以前从来没有注意到这一点。我认为通常 git 知道，提交已经通过拉取请求合并并且不会一次又一次地列出它们。
master 分支是否有问题，如果是，我该如何解决？
更多的合并策略可以参考下面的博客：
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 --squashfrom 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.