我试图在GitHub上审查一个拉请求到一个不是主的分支。目标分支在master后面,拉请求显示了来自master的提交,所以我合并了master并将其推送到GitHub,但刷新后,他们的提交和差异仍然出现在拉请求中。我已经再次检查了GitHub上的分支是否有来自master的提交。为什么它们仍然出现在拉请求中?
我还检查了本地拉请求,它只显示未合并的提交。
我试图在GitHub上审查一个拉请求到一个不是主的分支。目标分支在master后面,拉请求显示了来自master的提交,所以我合并了master并将其推送到GitHub,但刷新后,他们的提交和差异仍然出现在拉请求中。我已经再次检查了GitHub上的分支是否有来自master的提交。为什么它们仍然出现在拉请求中?
我还检查了本地拉请求,它只显示未合并的提交。
当前回答
这里有一个很好的变通办法。在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不会在拉请求中自动调整提交历史。最简单的解决方案是:
解决方案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的拉请求。
我不太确定这背后的理论。但我得到了这个几次,并能够通过做下面的事情来解决这个问题。
git pull --rebase
这将从您的原始回购主分支获取并合并更改(如果您有指向)
然后你把你的更改强行推到你的github克隆库(目标)
git push -f origin master
这将确保你的github克隆和你的父repo在相同的github提交级别,你不会看到跨分支的任何不必要的更改。
在我回答之前先说说我的问题
我将考虑3个分支,主控、测试和特性。
测试分支已经有了主要的变化。
当我将master合并到我的特性分支中,然后工作并提交到我的特性分支中,当我提出一个针对测试的PR时,它会再次显示已经在测试中的更改。这令人沮丧,我的同事没有遇到这个问题,因为他们使用命令提示符。我不希望使用命令提示符。
我使用GitHub桌面应用程序,这种情况经常发生在我身上,直到今天我才对此无能为力。
如果你在你的特性分支上有无数次提交(最多4-5次),只有 那么这个程序就有用了。如果有的话,你可能会感到困惑 大量的提交。
现在围绕GitHub桌面用户的工作:
从测试创建一个分支,命名为“feature-merge-to-testing” 选择那些提交到“特性合并到测试”。 解决冲突。 现在针对测试分支提出一个PR。 一旦完成,删除“特性-合并-测试”分支。
直到GitHub修复桌面应用程序中PRs的问题。我想我要按这个程序来,这似乎对我很管用。如果有什么有效的工作,请告诉我。
改变底数(这个问题的第一个答案)对我没用。
这发生在PRs被压缩和合并选项合并时。如果您希望旧的提交不显示在下面的pr中,那么只需使用创建合并提交选项合并这些pr。
创建合并提交 压缩和合并 重组和合并
注意:一旦完成,下一个pr总是显示他们自己的提交,而不是旧的,因为旧的已经通过创建合并提交选项添加到基础分支。
技术解释:merge -squash和rebase之间的区别是什么?