术语：
现在假设我的 origin/master 是上游/master 之前的一次提交
所以我为上游/主创建了一个拉取请求，并假设上游存储库的所有者接受拉取请求并合并它。
这会在上游存储库中创建一个 +1 提交，并带有消息“从 githubuser/branchname 合并的拉取请求”。所以现在在 github 上它显示“这个分支（origin/master）提前 1 个提交，在上游/主节点后面 1 个提交。” 虽然实际上，这些分支中的代码实际上是相同的，它们应该是偶数。
我试图通过去这里解决这个问题：在不推动的情况下清理分支，但它看起来更像是一个黑客。
有什么方法可以在不向上游进行额外提交的情况下推入上游。只是合并拉取请求，以便上游/主和源/主分支是偶数？
问题的核心在于 GitHub 内部。（我稍后会详细介绍。）因此，您的问题的答案是否定的：
有什么方法可以在不向上游进行额外提交的情况下推入上游。只是合并拉取请求，以便上游/主和源/主分支是偶数？
这里涉及四类人：
那些对 GitHub 本身进行编程的人。它们控制 Web 浏览器中显示的内容，即您在页面上看到的“合并此拉取请求”的绿色按钮，该按钮的边缘有一个小的下拉箭头，如果单击该箭头，您可以选择三种类型中的一种合并。
三种类型的合并不包括您想要的操作。因此，如果他们更改此设置以添加第四种类型的合并，或更改现有的三种类型中的一种，或类似的内容，则可以让第 3 组中的每个人都能够做你想做的事。
那些对上游存储库具有管理访问权限的人。他们可以git push直接访问上游存储库。这意味着他们可以使用命令行 Git（根本不是 GitHub）来执行您想要的操作，然后运行git push以更新 GitHub 上的存储库。
那些通过 GitHub 提供的接口对上游存储库具有写访问权限但没有管理访问权限的人。他们不能做你想做的事——至少，直到并且除非第 1 组的人将其添加为选项。
那些没有写权限的人（大概包括你自己）：他们做不到。
现在，对于那些 GitHub clicky 按钮——或者更确切地说，按钮单数，具有三种模式：三种提供的模式是这样标记的：
合并。
您可能认为这可以完成这项工作，但事实并非如此，因为它运行等效于. 该是明显不够的，而部分。这部分更棘手：它是在. 这是提交特定的ID提交您提交的，通过你的“比较和pull请求” clicky按钮的点击。git checkout branch && git merge --no-ff -m message hashbranchmessageMerge pull request #number from repositoryhashrefs/pull/number/head
如果GitHub的是使用的等效，与同和，你会得到你想要什么。当然，不会有包含 text 的提交。不过这样就好了。（这是我希望他们添加的新模式。他们可以将其称为Merge 而无需额外提交或Fast-forward，也许。）git checkout branch && git merge --ff-only hashbranchhashMerge pull request ...
变基和合并。
这会将当前不在分支上的拉取请求提交（可能有多个）添加到分支。它运行等效于（也许与或以及）。最终结果是来自拉取请求的提交被复制，而不是合并到具有新的和不同的哈希 ID 的新提交。合并请求在没有添加合并提交的情况下完成，所以没有消息。git checkout branch && git rebase --force-rebase hash--merge--strategy mergeMerged pull request ...
您可能会认为，如果要复制的一个或多个提交已经在正确的位置——即在单击按钮之前刚刚经过分支的尖端——GitHub 不会复制这些提交，而是直接使用它们照原样，如果他们运行相当于git rebase without --force-rebase or会发生的情况--no-ff。但这种情况并非如此。这是否有一些好的（GitHub 内部的）原因，我不知道。
挤压和合并。
这相当于. （这里是多余的：隐含。这是命令行 Git 实现的一个不必要的特性，因为如果你真的想要，你可以指定它。）git checkout branch && git merge --no-commit --squash hash && git commit -m message--no-commit--squash--no-commitgit merge --squash --no-commit
因为这使新提交与引入其效果的提交没有任何联系，所以这显然完全不适合实现您想要的。
对上游存储库具有写入权限的人可以将您的拉取请求放入他们控制的计算机上的 Git 存储库中，手动合并，然后将结果推送回 GitHub 上的上游存储库。这就是Tobias K. 在评论中提到的。那将实现你想要的。
如果 GitHub 要添加我希望他们添加的合并模式，那么当前将您的拉取请求与 Web-UI 合并按钮合并的用户将能够一步完成，而无需涉及他们自己的计算机和 Git 命令行命令。但如果没有这种额外的模式，他们就不能。
他们现在实际使用的是Rebase 和合并模式。正因如此，我们可以说：
所以现在在 github 上它显示“这个分支（origin/master）是 1 次提交，1 次提交落后于上游/主。 ”
如果他们使用Merge模式，您会看到自己落后于一次提交，而不是提前一次提交。这对你会更友好，但在某些方面，对他们自己（以及他们存储库的其他用户）不太友好。当他们使用衍合和合并他们最后复制所有提交的，所以如果你是ķ提交行动之前，你会突然成为ķ进取和 ķ背后：在ķ你是未来是你的提交，用你的哈希ID和你后面的k是他们提交的副本，以及他们的哈希 ID。
请注意，您可以通过在自己的计算机上执行以下操作来从中恢复：
git fetch upstream
git checkout $branch
git rebase upstream/$branch
git push --force-with-lease origin $branch
（其中$branch代表您的分支名称）。在fetch获得他们的提交复印件。在checkout为底垫的位置，你，其中rebase执行。1 在git push发送新的提交给你的叉子（如果它们尚不存在），然后请求GitHub上改变你的叉子的想法$branch，以点到最后这种复制的承诺，成功（仿佛--force），即使该下降部分提交，但--force-with-lease如果被删除的提交不完全符合预期，则失败 ( )。
1您实际上可以一步完成此操作，因为git rebase您可以在开始变基之前检查分支，但我认为这样更清晰。要一步完成，请使用git rebase origin/$branch $branch。