我找到了一种方法来获得正确的行为(在2020年11月测试)。

git合并和解决冲突后，需要使用git merge——continue而不是git commit ....

解决这个问题的偷懒方式: 手动编辑分支中已经在目标分支中的文件，使用从目标分支的文件复制的相同代码，并保存它。它被提交。现在，PR将自动更新您所做的新提交，从而解决问题。

解决这个问题的一种方法是git在PR中rebase targetbranch。然后git push -force targetbranch，然后Github会显示正确的提交和diff。如果你不知道你在做什么，请小心使用这个。也许先签出一个测试分支来做rebase，然后git diff targetbranch以确保它仍然是你想要的。

如果你太担心会把事情搞砸，可以采用故障安全方法: 转到文件并手动删除更改，然后使用最后一次提交压缩

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

我没有矛盾，你就好走了!

用2点url代替3点url来比较

而不是

http://githuburl/org/repo/compare/targetbranch...currentbranch

Use

http://githuburl/org/repo/compare/targetbranch..currentbranch

对于遇到这种情况并对GitHub Pull Request行为感到困惑的其他人来说，根本原因是PR是源分支尖端与源分支和目标分支的共同祖先之间的差异。因此，它将显示源分支上直到公共祖先的所有更改，而不会考虑目标分支上可能发生的任何更改。

更多信息请访问:https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

基于共同祖先的差异似乎很危险。我希望GitHub能够提供一个更标准的基于3方合并的PR。

编辑-我从来没有提到我总是使用明显的变通办法来避免由此产生的任何问题。只要定期将你的目标分支合并到你的PR分支中，你就不会遇到任何令人不快的意外。