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

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

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

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

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

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

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

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

而不是

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

Use

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

这里有一个很好的变通办法。在GitHub中查看PR时，使用Edit按钮将基本分支更改为master以外的内容。然后切换回master，现在它将正确地显示最近提交的更改。

我做了什么，为什么会这样?

没有一个解决方案对我有效。当我用两个点，即。。而不是……GH的差异更接近我所改变的。但这还不是我全部的改变。

这是因为GitHub显示压缩合并更改的方式存在问题。最好的解释在这里

它基本上发生在以下情况:

推送featureBranch的变化 挤压合并到主 在本地，当我仍然在featureBranch上时，我将它与main合并。做更多的修改，再把它推上去。 但后来在GitHub上，我看到了比我预期的更多的变化。

值得注意的是，这不是git的问题。相反，这是一个GitHub问题。GitHub无法判断压缩提交与非压缩提交的总和相同，从而导致额外的差异。

解决方案

在本地main上，撤消并保存所有未与main合并的更改。我做到了。例如，如果我有4个提交，不在我的PR得到壁球合并，那么我会这样做:

git重置头~4 Git保存“最近4次提交”

然后用刚才存储的内容创建一个新分支。步骤:

Git checkout main git checkout -b newBranch Git stash应用 Git add—all Git commit -m "some message" git推

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

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

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

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

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

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

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