tl;dr
整个DEV基础分支合并到我自己的分支
这是Github冲突解决流程的一个特点。
From 解决 Github 上的合并冲突 https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github: "8. 解决所有合并冲突后，单击“提交合并”。这会将整个基础分支合并到您的头分支中。“但他们没有解释原因。
这不好
这很令人惊讶，但也很好。下面我会解释一下。
如何才能避免这种情况呢？
不要回避它。但可以让这个过程更加顺利。
让您的分支与开发人员保持同步并解决任何冲突。然后提交 PR。
要在 Github 上执行此操作：提交您的 PR 草稿 https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests;解决Github上的冲突；将其标记为可供审核。通过从草稿开始，您可以避免人们在冲突解决完成之前审查您的代码。
要在命令行上执行此操作：
# Bring dev up to date
$ git checkout dev
$ git pull
# Update your branch with the latest dev
$ git checkout <your branch>
$ git rebase dev # or git merge dev
请注意，是的，您在提交要合并到 dev 的分支之前将 dev 合并到您的分支中。这是使分支更新的正常过程。
您应该习惯性地更新您的分支，以减少分支和开发人员之间的偏差。这将使冲突解决方案更小且更易于管理。
你这样做吗，Github？
与任何审核流程一样，Github PR 流程的目的是检查合并结果是否有效。这可能涉及自动检查 https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-status-checks、运行分支的测试以及手动审核。
让我们考虑一下它是否如您所愿。您的 PR 通过了所有检查。你点击合并按钮，就会出现冲突。您解决冲突并直接合并到开发中。
如果您在解决冲突时犯了错误怎么办？
已解析的代码不是已审核的代码。合并冲突表明开发中发生了您不知道且没有考虑到的更改。您刚刚编辑了分支来修复该问题，并且该工作尚未经过检查。如果立即合并到开发中，就没有什么可以阻止你的 PR 破坏每个人的开发。
相反，Github PR 需要像任何其他编辑一样对待手动冲突解决。与任何其他编辑一样，必须重新检查。已解析的代码必须位于存储库中的某个位置。因此，Github 将 dev 与冲突解决方案一起合并到您的分支中，就像您在提交 PR 之前更新了分支一样。现在可以重新检查您的分支是否有错误。解析后的代码通过了检查，可以安全地合并。
所以 Github 正在做你应该在命令行上做的同样的事情。从开发更新您的分支，解决所有冲突，检查结果，然后合并。
注意：这是我的一个有根据的猜测。我对Github没有什么特别的见解。
最后，功能分支是短暂的。合并后应将其删除 https://stackoverflow.com/questions/29316225/why-should-i-delete-feature-branches-when-merged-to-master/29319178#29319178。只要结果正确，具体的合并过程并不太重要。
