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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对于遇到这种情况并对GitHub Pull Request行为感到困惑的其他人来说，根本原因是PR是源分支尖端与源分支和目标分支的共同祖先之间的差异。因此，它将显示源分支上直到公共祖先的所有更改，而不会考虑目标分支上可能发生的任何更改。

更多信息请访问:https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

基于共同祖先的差异似乎很危险。我希望GitHub能够提供一个更标准的基于3方合并的PR。

编辑-我从来没有提到我总是使用明显的变通办法来避免由此产生的任何问题。只要定期将你的目标分支合并到你的PR分支中，你就不会遇到任何令人不快的意外。

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

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