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

我试图在GitHub上审查一个拉请求到一个不是主的分支。目标分支在master后面，拉请求显示了来自master的提交，所以我合并了master并将其推送到GitHub，但刷新后，他们的提交和差异仍然出现在拉请求中。我已经再次检查了GitHub上的分支是否有来自master的提交。为什么它们仍然出现在拉请求中?

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

200355 次浏览
小开
最佳答案

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

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

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

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

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

你确定要改变底色吗?

从旧的基本分支中提交的一些文件可能会从 时间轴，旧的评论可能会过时。

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

enter image description here

小开

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

更多信息可在这里:https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

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

小开

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

小开

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

git pull --rebase

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

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

git push -f origin master

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

小开

你需要在你的~/.gitconfig文件中添加以下内容:

[rebase]
autosquash = true

这将自动实现与这个答案所显示的相同的效果。

我从在这里得到这个。

小开

综上所述，GitHub不会在拉请求中自动调整提交历史。最简单的解决方案是:

解决方案1:调整基数

假设你想从feature-01合并到master:

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

如果你正在使用一个fork，那么你可能需要用upstream替换上面的origin。参见我如何更新一个GitHub分叉库?< / >了解更多关于跟踪原始存储库的远程分支的信息。

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

假设你想从feature-01中合并引入master:

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

现在打开feature-01-rebased的拉请求，关闭feature-01的拉请求。

小开

这里有一个很好的变通办法。在GitHub中查看PR时，使用Edit按钮将基本分支更改为master以外的内容。然后将其切换回master，现在它将正确地显示最近提交的更改。

小开

如果你太担心把事情搞砸了，可以使用故障安全方法: 转到文件并手动删除更改，然后使用

压缩最后一次提交 
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})"

我没有矛盾，你就好走了!

小开

这发生在GitHub中，当你压缩从目标分支合并的提交时。

我一直使用挤压和合并Github作为默认的合并策略，包括从目标分支合并。这引入了一个新的提交，GitHub不识别这个压缩提交与master中已经存在的提交相同(但具有不同的哈希值)。Git可以很好地处理它，但你在GitHub中再次看到所有的变化，这让人讨厌。解决方案是在上游提交中对这些数据进行常规合并，而不是压缩和合并。当你想要将另一个分支作为依赖项合并到你的分支中时，git merge --squash并在另一个分支实际成为主分支后从master中提取之前恢复那个单独的提交。

编辑:另一种解决方案是重新基底和强制推。干净但被改写的历史

小开

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

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

小开

用2点url代替3点url来比较

而不是

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

使用

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

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

没有一个解决方案对我有效。当我使用两个点，即..而不是...时，GH上的差异更接近我所改变的。但这还不是我全部的改变。

这是因为GitHub显示南瓜合并变化的方式存在问题。最好解释在这里

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

  1. 上推featureBranch的变化
  2. 南瓜合并它变成main
  3. 在本地，当我仍然在featureBranch上时，我将它与main合并。做更多的修改，再把它推上去。
  4. 但后来在GitHub上，我看到了比我预期的更多的变化。

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

解决方案

在你的本地主机上，撤消并隐藏所有未合并的更改 with main。我做到了。例如，如果我有4个提交，不在我的PR得到壁球合并，那么我会这样做:

  • 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
小开

一旦我在开始新的改变或创建PR之前开始做以下事情，这个问题就不会发生在我身上。

git pull --rebase origin <target-branch>

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

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

使用git cherry-pick

如果重基过程对您来说像对我一样混乱，另一个选择是使用git精选。以下是步骤:

  • 使用git pull更新你的本地目标分支。
  • 签出您所做更改的分支并复制您想要的提交的提交id。如果分支名称是tangled，执行git checkout tangled，然后执行git log。您可以使用键盘上的向上/向下箭头滚动git日志输出。提交id是每次提交所包含的长数字。
  • 当你在目标分支上时，使用git checkout -b new-branch-name从你的目标分支(例如main)创建一个新分支。
  • 在新的分支中，执行git cherry-pick commit-id，其中commit-id是你从git log中复制的长数字，它标识了你想要推送的提交。您可以多次执行此操作，每次更改id以获得另一次提交。
  • 如果你在你创建的这个新分支上运行git log，你可以看到只有你添加的更改存在于目标分支的头之后，正如预期的那样。
  • 最后，使用git push origin new-branch-name将更改推到远程并创建一个拉请求。
小开

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

我将考虑3个分支，< >强主< / >强， < >强测试< / >强， < >强劲功能< / >强。

< >强测试< / >强分支将会有< >强主< / >强的变化。

当我将< >强主< / >强合并到我的< >强劲功能< / >强分支，然后工作并提交到我的< >强劲功能< / >强分支时，问题出现了，当我对< >强测试< / >强引发公关时，它再次显示< >强测试< / >强中的已经更改。这是令人沮丧的和我的同事不面对这个问题，因为他们使用命令提示符。和< >强劲功能< / >强0来使用命令提示符。

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

如果你在你的< >强劲功能< / >强分支上有可数提交 (4-5 max)，只有 那么这个程序就有用了。如果有，你可以得到困惑 大量的提交。

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

  1. 从< >强测试< / >强创建一个分支，命名为“__abc1”;
  2. 择优挑选那些提交到"< >强feature-merge-to-testing < / >强"。
  3. 解决冲突。
  4. 现在对< >强测试< / >强分支引发公关。
  5. 删除&;< >强feature-merge-to-testing < / >强"分支一旦完成。

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

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


提交答案