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

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


当前回答

使用git的精选

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

Update your local target branch using git pull. checkout the branch where you made changes and copy the commit IDs of the commits you want. if the branch name is tangled, do git checkout tangled and then git log. You can scroll through the git log output using the up/down arrows on the keyboard. The commit IDs are the long numbers that each commit contains. Create a new branch from your target branch (e.g main) using git checkout -b new-branch-name when you are on the target branch. On the new branch, do git cherry-pick commit-id where commit-id is the long number that you copied from git log which identifies the commit you want to push. You can do this multiple times, changing the id each time to get another commit. If you run git log on this new branch which you created, you can see that only the changes you have added exist after your target branch's head, as expected. Lastly, push the changes to remote using git push origin new-branch-name and create a pull request.

其他回答

这发生在PRs被压缩和合并选项合并时。如果您希望旧的提交不显示在下面的pr中,那么只需使用创建合并提交选项合并这些pr。

创建合并提交 压缩和合并 重组和合并

注意:一旦完成,下一个pr总是显示他们自己的提交,而不是旧的,因为旧的已经通过创建合并提交选项添加到基础分支。

技术解释:merge -squash和rebase之间的区别是什么?

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

我将考虑3个分支,主控、测试和特性。

测试分支已经有了主要的变化。

当我将master合并到我的特性分支中,然后工作并提交到我的特性分支中,当我提出一个针对测试的PR时,它会再次显示已经在测试中的更改。这令人沮丧,我的同事没有遇到这个问题,因为他们使用命令提示符。我不希望使用命令提示符。

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

如果你在你的特性分支上有无数次提交(最多4-5次),只有 那么这个程序就有用了。如果有的话,你可能会感到困惑 大量的提交。

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

从测试创建一个分支,命名为“feature-merge-to-testing” 选择那些提交到“特性合并到测试”。 解决冲突。 现在针对测试分支提出一个PR。 一旦完成,删除“特性-合并-测试”分支。

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

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

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

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

git pull --rebase origin <target-branch>

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

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

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

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

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

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

你确定要改变底色吗? 类中的旧基本分支中的一些提交可能会被删除 时间轴,旧的评论可能会过时。

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