我试图在GitHub上审查一个拉请求到一个不是主的分支。目标分支在master后面,拉请求显示了来自master的提交,所以我合并了master并将其推送到GitHub,但刷新后,他们的提交和差异仍然出现在拉请求中。我已经再次检查了GitHub上的分支是否有来自master的提交。为什么它们仍然出现在拉请求中?
我还检查了本地拉请求,它只显示未合并的提交。
我试图在GitHub上审查一个拉请求到一个不是主的分支。目标分支在master后面,拉请求显示了来自master的提交,所以我合并了master并将其推送到GitHub,但刷新后,他们的提交和差异仍然出现在拉请求中。我已经再次检查了GitHub上的分支是否有来自master的提交。为什么它们仍然出现在拉请求中?
我还检查了本地拉请求,它只显示未合并的提交。
当前回答
我不太确定这背后的理论。但我得到了这个几次,并能够通过做下面的事情来解决这个问题。
git pull --rebase
这将从您的原始回购主分支获取并合并更改(如果您有指向)
然后你把你的更改强行推到你的github克隆库(目标)
git push -f origin master
这将确保你的github克隆和你的父repo在相同的github提交级别,你不会看到跨分支的任何不必要的更改。
其他回答
解决这个问题的偷懒方式: 手动编辑分支中已经在目标分支中的文件,使用从目标分支的文件复制的相同代码,并保存它。它被提交。现在,PR将自动更新您所做的新提交,从而解决问题。
在我回答之前先说说我的问题
我将考虑3个分支,主控、测试和特性。
测试分支已经有了主要的变化。
当我将master合并到我的特性分支中,然后工作并提交到我的特性分支中,当我提出一个针对测试的PR时,它会再次显示已经在测试中的更改。这令人沮丧,我的同事没有遇到这个问题,因为他们使用命令提示符。我不希望使用命令提示符。
我使用GitHub桌面应用程序,这种情况经常发生在我身上,直到今天我才对此无能为力。
如果你在你的特性分支上有无数次提交(最多4-5次),只有 那么这个程序就有用了。如果有的话,你可能会感到困惑 大量的提交。
现在围绕GitHub桌面用户的工作:
从测试创建一个分支,命名为“feature-merge-to-testing” 选择那些提交到“特性合并到测试”。 解决冲突。 现在针对测试分支提出一个PR。 一旦完成,删除“特性-合并-测试”分支。
直到GitHub修复桌面应用程序中PRs的问题。我想我要按这个程序来,这似乎对我很管用。如果有什么有效的工作,请告诉我。
改变底数(这个问题的第一个答案)对我没用。
这发生在GitHub中,当你压缩从目标分支合并的提交时。
I had been using squash and merge with Github as the default merge strategy, including merges from the target branch. This introduces a new commit and GitHub doesn't recognize that this squashed commit is the same as the ones already in master (but with different hashes). Git handles it properly but you see all the changes again in GitHub, making it annoying to review. The solution is to do a regular merge of these pulled in upstream commits instead of a squash and merge. When you want to merge in another branch into yours as a dependency, git merge --squash and revert that single commit before pulling from master once that other branch has actually made it to master.
编辑:另一种解决方案是重新基底和强制推。干净但被改写的历史
综上所述,GitHub不会在拉请求中自动调整提交历史。最简单的解决方案是:
解决方案1:调整基数
假设你想从feature-01合并到master:
git fetch origin
git checkout feature-01
git rebase origin/master
git push --force-with-lease
如果你在一个分叉上工作,那么你可能需要用上游替换上面的原点。参见如何更新GitHub分叉存储库?了解有关跟踪原始存储库的远程分支的更多信息。
解决方案2:创建一个新的拉请求
假设你想从feature-01中合并介绍master:
git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased
现在打开一个基于feature-01-re - based的拉请求,并关闭feature-01的拉请求。
我做了什么,为什么会这样?
没有一个解决方案对我有效。当我用两个点,即。。而不是……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推