GitHub拉取请求显示已在目标分支中的提交


136

我正在尝试查看GitHub上对非主分支的请求请求。目标分支位于master后面,并且pull请求显示来自master的提交,因此我合并了master并将其推送到GitHub,但是刷新后它们的提交和diff仍然出现在pull请求中。我已经仔细检查了GitHub上的分支是否具有master的提交。为什么它们仍出现在拉取请求中?

我还在本地签出了pull请求,它只显示未合并的提交。


这会影响PR合并的行为吗?
内森·欣奇

不,只是Github上的差异。
lobati

有谁知道自托管的Gitlab是否遭受相同的行为?
Jeff Welling

2
我建议我们都与GitHub联系以表达我们对更改此行为的兴趣(support.github.com/contact)。如果他们没有收到我们的来信,那么他们将不知道这有多重要,而且永远都是这样。
steinybot

Answers:


106

看起来,“拉取请求”无法跟踪目标分支的更改(我联系了GitHub支持,并于2014年11月18日收到了回复,指出这是设计使然)。

但是,您可以通过执行以下操作来显示更新的更改:

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

更换githuburlorgrepotargetbranch,和currentbranch需要。

或者,正如hexsprite在他的答案中指出的那样,您也可以通过单击EditPR并将其临时更改为另一个分支,然后再次返回来强制更新它。这将产生警告:

您确定要更改基准吗?

来自旧基础分支的某些提交可能会从时间轴中删除,并且旧的评论可能会过时。

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

在此处输入图片说明


4
是的,我不久前联系了支持人员,得到了同样的答复。他们没有针对这种情况进行优化。这有点令人沮丧。我们解决该问题的方法是重新调整并强制向上推,或者关闭拉力并创建一个新推力。
lobati 2014年

4
这个答案不能解决问题,而只是允许用户看到真正的差异。
FearlessFuture

4
问题是“为什么它们仍出现在拉取请求中?”。它回答了这个问题。
亚当·米勒基普

3
查看我的评论以寻求一个好的解决方法。您可以简单地使用PR编辑按钮切换到另一个分支,然后再回到原始的基础分支,它将重新计算差异。
hexsprite

11
是否有亲爱的github请求来进行更改?
vossad01

86

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


4
令我惊讶的是,更多的人不认可这种解决方案。我怀疑原始的过时拉取请求就可以了,但是我不喜欢GitHub显示所有过时的文件,所以我使用了它,它既保留了注释,又只显示了将要合并的实际更改。 。谢谢!
taranaki

2
没有为我工作。
沙申克

该死的作品!
Anurag Hazra

三年后,这仍然是一个很好的解决方案。看起来有人在几个小时前也发表了评论^^^
Ricardo Saporta

32

综上所述,GitHub不会在拉取请求中自动将提交历史记录作为基准。最简单的解决方案是:

解决方案1:变基

假设你要合并到master来自feature-01

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

如果您使用的是叉子,则可能需要用替换origin以上内容upstream。请参阅如何更新GitHub分叉存储库?了解有关跟踪原始存储库的远程分支的更多信息。

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

假设您要合并master来自的简介feature-01

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

现在打开的拉取请求,feature-01-rebased并关闭的拉取请求feature-01


4
重新设置基础会更改提交哈希,是否最终会浪费现有的评论?
haridsv

@haridsv可能是。
Mateusz Piotrowski

在进行推力时需要注意什么?
Paul Bendevis,

1
@haridsv,这不是我的经验。我经常对中审定基,评论也不会丢失。虽然我确实失去了PR变化的历史
乔尔

@JoelBerkeley实际上,我同时经历了几条评论,在这些评论中,作者重新定位并观察到评论是完整的。但是,我们失去了逐步进行审阅的能力,对于大型审阅,这对审阅者来说是一个巨大的惩罚。现在,我们有一些关于PR的准则,其中一个准则是在审查开放后再也没有根据(除非有人确定没有人开始审查)。合并很好,但我们的准则是不要将合并更改与冲突解决方案以外的任何其他更改混合使用。
haridsv

16

您需要将以下内容添加到~/.gitconfig文件中:

[rebase]
    autosquash = true

这将自动实现与该答案相同的结果所示结果。

我从这里得到的。


2
该死的,我不小心点击了否决票。这个答案帮助了我。请允许我更改它。
Hector

@hosein去吧。您现在应该可以这样做。
Mateusz Piotrowski

1
我认为这应该是接受的答案,也应该包含在接受的答案中。这样可以达到我想要的结果!
罗纳德·雷

1
@RonaldRey git rebasing不是通用解决方案,因为它涉及到编辑历史记录。如果每个人都在使用从未被其他人克隆的私有fork,那很好,但是只要有人克隆您的存储库,然后您编辑历史记录,您就会得到不同的历史记录。
亚当·米勒基普

14

对于遇到此问题并被GitHub Pull Request行为所迷惑的其他人,根本原因是PR是源分支提示与源分支和目标分支的共同祖先的区别。因此,它将显示源分支上直到公共祖先的所有更改,并且不会考虑目标分支上可能发生的任何更改。

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

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


1
您提到的原因似乎是正确的,但我感到困惑,因为通常每当主服务器更新时,我都会将更改反向合并到我的分支... git checkout my-branch-> git merge master。拉取请求会立即刷新。共同祖先也会更新吗?
G.One 2013年

2
当执行
重新基准

1
@ G.One,真的很晚了,但是是的-如果您从该master分支合并到您的source分支,则根据定义,您已经更新了共同祖先。这是您合并的母版上的提交。
大卫·赫斯

13

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


10

当您从目标分支合并提交时,在GitHub上会发生这种情况。

我一直在使用壁球并将Github合并为默认合并策略,包括来自目标分支的合并。这引入了一个新的提交,并且GitHub无法识别此压缩的提交与已经在master中的提交相同(但是具有不同的哈希值)。Git可以正确处理它,但是您会在GitHub上再次看到所有更改,因此很烦人。解决方案是对这些拉入的上游提交进行定期合并,而不是压缩合并。当您想将另一个分支作为一个依赖项合并到您的分支中,git merge --squash并在该分支实际成为master分支之后,再从master撤回该单个提交。

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


1
谢谢@achille,这确实是我这方面的问题。禁用南瓜合并后,将解决该问题。
Ashvin777

0

我不确定这背后的理论。但是我得到了好几次,并能够通过以下操作解决此问题。

git pull --rebase

这将从原始repo master分支中获取并合并更改(如果您有指向的话)

然后,将更改强行推送到github克隆的存储库(目标)

git push -f origin master

这将确保您的github克隆和您的父仓库位于同一github提交级别,并且您不会在分支之间看到任何不必要的更改。



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

我没有冲突,你很好!

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.