综上所述，GitHub不会在拉请求中自动调整提交历史。最简单的解决方案是:

解决方案1:调整基数

假设你想从feature-01合并到master:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force-with-lease

如果你在一个分叉上工作，那么你可能需要用上游替换上面的原点。参见如何更新GitHub分叉存储库?了解有关跟踪原始存储库的远程分支的更多信息。

解决方案2:创建一个新的拉请求

假设你想从feature-01中合并介绍master:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

现在打开一个基于feature-01-re - based的拉请求，并关闭feature-01的拉请求。

我找到了一种方法来获得正确的行为(在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})"

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

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

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

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

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

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

没有一个解决方案对我有效。当我用两个点，即。。而不是……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推

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

git pull --rebase origin <target-branch>

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