一旦我在开始新的改变或创建PR之前开始做以下事情，这个问题就不会发生在我身上。

git pull --rebase origin <target-branch>

这基本上确保了从本地添加的任何新更改都堆叠在当前远程分支中的内容之上。因此，我们的本地分支总是在当前远程头的顶部，只有新的提交在PR中。

一旦我在开始新的改变或创建PR之前开始做以下事情，这个问题就不会发生在我身上。

git pull --rebase origin <target-branch>

这基本上确保了从本地添加的任何新更改都堆叠在当前远程分支中的内容之上。因此，我们的本地分支总是在当前远程头的顶部，只有新的提交在PR中。

在我回答之前先说说我的问题

我将考虑3个分支，主控、测试和特性。

测试分支已经有了主要的变化。

当我将master合并到我的特性分支中，然后工作并提交到我的特性分支中，当我提出一个针对测试的PR时，它会再次显示已经在测试中的更改。这令人沮丧，我的同事没有遇到这个问题，因为他们使用命令提示符。我不希望使用命令提示符。

我使用GitHub桌面应用程序，这种情况经常发生在我身上，直到今天我才对此无能为力。

如果你在你的特性分支上有无数次提交(最多4-5次)，只有 那么这个程序就有用了。如果有的话，你可能会感到困惑 大量的提交。

现在围绕GitHub桌面用户的工作:

从测试创建一个分支，命名为“feature-merge-to-testing” 选择那些提交到“特性合并到测试”。 解决冲突。 现在针对测试分支提出一个PR。 一旦完成，删除“特性-合并-测试”分支。

直到GitHub修复桌面应用程序中PRs的问题。我想我要按这个程序来，这似乎对我很管用。如果有什么有效的工作，请告诉我。

改变底数(这个问题的第一个答案)对我没用。

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

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

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

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

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})"

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