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

我将考虑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以确保它仍然是你想要的。

我不太确定这背后的理论。但我得到了这个几次，并能够通过做下面的事情来解决这个问题。

git pull --rebase

这将从您的原始回购主分支获取并合并更改(如果您有指向)

然后你把你的更改强行推到你的github克隆库(目标)

git push -f origin master

这将确保你的github克隆和你的父repo在相同的github提交级别，你不会看到跨分支的任何不必要的更改。

这发生在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推

综上所述，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的拉请求。