280

我正在尝试在 GitHub 上查看非主分支的拉取请求。目标分支在 master 后面，pull request 显示 master 提交，所以我合并 master 并推送到 GitHub，但是刷新后它们的提交和差异仍然出现在 pull request 中。我已经检查了 GitHub 上的分支是否有来自 master 的提交。为什么它们仍然出现在拉取请求中？

我还在本地检查了拉取请求，它只显示未合并的提交。

4

13 回答 13

199

这是一个很好的解决方法。在 GitHub 中查看 PR 时使用该Edit按钮将基本分支更改为master. 然后将其切换回master，它现在将正确显示最近提交的更改。

于 2017-10-17T04:50:03.013 回答
161

看起来拉取请求没有跟踪目标分支的更改（我联系了 GitHub 支持，并在 2014 年 11 月 18 日收到回复，说明这是设计使然）。

但是，您可以通过执行以下操作让它向您显示更新的更改：

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

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

或者正如 hexsprite 在他的回答中指出的那样，您也可以通过单击EditPR 并暂时将基础更改为不同的分支并再次返回来强制它更新。这会产生警告：

您确定要更改基础吗？

来自旧基础分支的一些提交可能会从时间线中删除，旧评论可能会过时。

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

在此处输入图像描述

于 2014-11-18T03:54:06.150 回答
68

总而言之，GitHub 不会在拉取请求中自动变基提交历史记录。最简单的解决方案是：

解决方案 1：变基

假设您要合并到masterfrom feature-01：

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

如果您正在使用 fork，那么您可能需要将origin上面替换为upstream. 请参阅如何更新 GitHub 分叉存储库？了解有关跟踪原始存储库的远程分支的更多信息。

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

假设您要合并 intro masterfrom feature-01：

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

现在打开一个拉取请求feature-01-rebased并关闭一个feature-01。

于 2017-07-24T17:39:51.127 回答
26

对于遇到此问题并被 GitHub 拉取请求行为混淆的任何其他人，根本原因是 PR 是源分支提示与源分支和目标分支的共同祖先的差异。因此，它将显示源分支上直到共同祖先的所有更改，并且不会考虑目标分支上可能发生的任何更改。

此处提供更多信息：https ://developer.atlassian.com/blog/2015/01/a-better-pull-request/

基于共同祖先的差异似乎很危险。我希望 GitHub 可以选择制作更标准的基于 3 路合并的 PR。

于 2016-02-04T14:18:06.950 回答
26

当您压缩从目标分支合并的提交时，GitHub 会发生这种情况。

我一直使用 squash 并与 Github 合并作为默认合并策略，包括来自目标分支的合并。这引入了一个新的提交，并且 GitHub 不承认这个压缩的提交与 master 中已经存在的提交相同（但具有不同的哈希值）。Git 可以正确处理它，但您会在 GitHub 中再次看到所有更改，这让查看起来很烦人。解决方案是定期合并这些拉入的上游提交，而不是压缩和合并。当您想将另一个分支作为依赖项合并到您的分支中，git merge --squash并在其他分支实际成为主分支后从主分支拉出之前恢复该单个提交。

编辑：另一种解决方案是变基并强制推送。干净但改写的历史

于 2019-03-19T23:16:55.537 回答
23

You need to add the following to your ~/.gitconfig file:

[rebase]
    autosquash = true

This will automatically achieve the same as what this answer shows.

I got this from here.

于 2017-03-20T16:57:06.560 回答
14

解决此问题的一种方法是git rebase targetbranch在该 PR 中。然后git push --force targetbranch，Github 将显示正确的提交和差异。如果您不知道自己在做什么，请注意这一点。也许先签出一个测试分支来做rebase，然后git diff targetbranch确保它仍然是你想要的。

于 2016-06-24T14:53:26.940 回答
7

而不是 3-dot url 使用 2-dot url 来比较

代替

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

利用

http://githuburl/org/repo/compare/targetbranch..currentbranch
于 2021-03-10T01:17:47.040 回答
3

我尝试了什么以及为什么会这样？

没有一个解决方案对我有用。当我使用两个点ie..而不是...GH 上的差异时，它更接近于我所做的更改。但仍然不是我所有的变化。

发生这种情况是因为 GitHub 显示squash 合并更改的方式存在问题。最好在这里解释

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

  1. 推动变化featureBranch
  2. 壁球合并成main
  3. 当我还在本地时，featureBranch我将它与main. 进行更多更改并再次推动它。
  4. 但是在 GitHub 上，我看到的变化比我预期的要多。

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

解决方案

在您的本地 main 上，撤消并存储所有尚未与 main 合并的更改。为此，我做到了。例如，如果我的 PR 中没有 4 个提交被壁球合并，那么我会这样做：

  • git reset HEAD~4
  • git stash save "last 4 commits"

然后用你刚刚隐藏的东西创建一个新分支。脚步：

  • git checkout main
  • git checkout -b newBranch
  • git stash apply
  • git add --all
  • git commit -m "some message"
  • git push
于 2021-09-23T20:19:13.337 回答
0

我找到了一种获得正确行为的方法（在 2020 年 11 月测试）。

在git merge和解决冲突之后需要使用git merge --continue而不是git commit ....

于 2020-12-09T09:18:45.007 回答
0

一旦我在开始新的更改或创建 PR 之前开始执行以下操作，这个问题就不会发生在我身上。

git pull --rebase origin <target-branch>

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

于 2022-01-05T15:37:07.930 回答
0

我不太确定这背后的理论。但是我得到了几次，并且能够通过执行以下操作来解决这个问题。

git pull --rebase

这将从您的原始 repo master 分支获取并合并更改（如果您有这一点）

然后您将更改强制推送到您的 github 克隆存储库（目标）

git push -f origin master

这将确保您的 github 克隆和您的父 repo 处于相同的 github 提交级别，并且您不会在分支之间看到任何不必要的更改。

于 2016-12-18T13:55:22.387 回答
-1

如果您太担心搞砸了，请采取安全措施：转到文件并手动删除更改，然后使用您的最后一次提交进行压缩

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

我没有冲突，你很高兴！

于 2018-07-20T17:35:00.533 回答