看起来Pull Request没有跟踪目标分支的变化(我联系了GitHub支持，并在2014年11月18日收到了回复，说这是故意的)。

但是，你可以通过以下方法让它显示更新后的更改:

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

根据需要替换githuburl, org, repo, targetbranch和currentbranch。

或者正如hexsprite在他的回答中所指出的，你也可以通过点击PR上的Edit来强制它进行更新，并临时将基础更改为不同的分支，然后再返回。这会产生警告:

你确定要改变底色吗? 类中的旧基本分支中的一些提交可能会被删除 时间轴，旧的评论可能会过时。

并将在PR中留下两个日志条目:

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

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

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

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

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

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

这发生在PRs被压缩和合并选项合并时。如果您希望旧的提交不显示在下面的pr中，那么只需使用创建合并提交选项合并这些pr。

创建合并提交 压缩和合并 重组和合并

注意:一旦完成，下一个pr总是显示他们自己的提交，而不是旧的，因为旧的已经通过创建合并提交选项添加到基础分支。

技术解释:merge -squash和rebase之间的区别是什么?

这发生在GitHub中，当你压缩从目标分支合并的提交时。

I had been using squash and merge with Github as the default merge strategy, including merges from the target branch. This introduces a new commit and GitHub doesn't recognize that this squashed commit is the same as the ones already in master (but with different hashes). Git handles it properly but you see all the changes again in GitHub, making it annoying to review. The solution is to do a regular merge of these pulled in upstream commits instead of a squash and merge. When you want to merge in another branch into yours as a dependency, git merge --squash and revert that single commit before pulling from master once that other branch has actually made it to master.

编辑:另一种解决方案是重新基底和强制推。干净但被改写的历史