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

GitHub pull request showing commits that are already in target branch

提问by lobati

I'm trying to review a pull request on GitHub to a branch that isn't master. The target branch was behind master and the pull request showed commits from master, so I merged master and pushed it to GitHub, but the commits and diff for them still appear in the pull request after refreshing. I've doubled checked that the branch on GitHub has the commits from master. Why are they still appearing in the pull request?

我正在尝试将 GitHub 上的拉取请求到非主分支。目标分支在 master 后面，pull request 显示来自 master 的提交，所以我合并 master 并将其推送到 GitHub，但刷新后它们的 commits 和 diff 仍然出现在 pull request 中。我已经加倍检查了 GitHub 上的分支是否有来自 master 的提交。为什么它们仍然出现在拉取请求中？

I've also checked out the pull request locally and it only shows the un-merged commits.

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

采纳答案by Adam Millerchip

It looks like the Pull Request doesn't keep track of changes to the target branch (I contacted GitHub support, and received a response on 18 Nov 2014 stating this is by design).

看起来 Pull Request 没有跟踪目标分支的更改（我联系了 GitHub 支持，并在 2014 年 11 月 18 日收到了回复，说明这是设计使然）。

However, you can get it to show you the updated changes by doing the following:

但是，您可以通过执行以下操作让它向您显示更新的更改：

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

Replace githuburl, org, repo, targetbranch, and currentbranchas needed.

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

Or as hexsprite pointed out in his answer, you can also force it to update by clicking Editon the PR and temporarily changing the base to a different branch and back again. This produces the warning:

或者正如 hexsprite 在他的回答中指出的那样，您也可以通过单击EditPR 并暂时将基础更改为不同的分支并再次返回来强制它更新。这会产生警告：

Are you sure you want to change the base?

Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.

您确定要更改基数吗？

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

And will leave two log entriesin the PR:

并且会在 PR 中留下两个日志条目：

回答by hexsprite

Here's a good workaround. Use the Editbutton when viewing the PR in GitHub to change the base branch to something other than master. Then switch it back to masterand it will now correctly show only the changes from the most recent commits.

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

回答by Mateusz Piotrowski

To sum up, GitHub does not rebase the commit history automatically in pull requests. The simplest solutions are:

总而言之，GitHub 不会在拉取请求中自动重新设置提交历史记录。最简单的解决方案是：

Solution 1: Rebase

解决方案 1：变基

Suppose that you want to merge into masterfrom feature-01:

假设您要合并到masterfrom feature-01：

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

If you are working on a fork then you might need to replace originabove with upstream. See How do I update a GitHub forked repository?to learn more about tracking remote branches of the original repository.

如果您正在使用叉子，那么您可能需要将origin上面的upstream. 请参阅如何更新 GitHub 分叉存储库？了解有关跟踪原始存储库远程分支的更多信息。

Solution 2: Create a new pull request

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

Suppose that you want to merge intro masterfrom feature-01:

假设您master要从feature-01以下内容合并介绍：

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

Now open a pull request for feature-01-rebasedand close the one for feature-01.

现在打开一个拉取请求feature-01-rebased并关闭一个 for feature-01。

回答by David K. Hess

For anyone else coming across this and confused by GitHub Pull Request behavior, the root cause is that a PR is a diff of the source branch tip against the common ancestor of the source branch and the target branch. It will therefore show all changes on the source branch up to the common ancestor and will not take into account any changes that may have occurred on the target branch.

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

More information available here: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

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

Common ancestor based diffs seem dangerous. I wish GitHub had an option to make a more standard 3-way merge-based PR.

基于共同祖先的差异似乎很危险。我希望 GitHub 有一个选项来制作更标准的基于 3 路合并的 PR。

回答by Elijah Lynn

One way to fix this is to git rebase targetbranchin that PR. Then git push --force targetbranch, then Github will show the right commits and diff. Be careful with this if you don't know what you are doing. Maybe checkout a test branch first to do the rebase then git diff targetbranchto make sure it is still what you want.

解决这个问题的一种方法是git rebase targetbranch在那个 PR 中。然后git push --force targetbranch，然后 Github 将显示正确的提交和差异。如果您不知道自己在做什么，请注意这一点。也许先检出一个测试分支来做 rebase，然后git diff targetbranch确保它仍然是你想要的。

回答by Elena

You need to add the following to your ~/.gitconfigfile:

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

[rebase]
    autosquash = true

This will automatically achieve the same as what this answershows.

这将自动实现与此答案显示的相同。

I got this from here.

我从这里得到了这个。

回答by achille

This happens with GitHub when you squash commits merged in from the target branch.

当您压缩从目标分支合并的提交时，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 --squashand revert that single commit before pulling from master once that other branch has actually made it to master.

我一直在使用壁球并与 Github 合并作为默认合并策略，包括来自目标分支的合并。这引入了一个新的提交，GitHub 不承认这个压缩的提交与 master 中已经存在的提交相同（但具有不同的哈希值）。Git 会正确处理它，但您会在 GitHub 中再次看到所有更改，这让查看起来很烦人。解决方案是对上游提交的这些进行定期合并，而不是压缩和合并。当您想将另一个分支作为依赖项合并到您的分支中时，git merge --squash并在从 master 拉取之前恢复该单个提交，一旦该其他分支实际使其成为 master 分支。

EDIT: another solution is to rebase and force push. Clean but rewritten history

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

回答by Amit kumar

Try the below commands, one by one.

一一尝试以下命令。

git pull "latest

git reset --hard master

回答by Chanaka udaya

I'm not exactly sure about the theory behind this. But I got this several times and able to fix this by doing the following.

我不太确定这背后的理论。但是我得到了几次，并且能够通过执行以下操作来解决这个问题。

git pull --rebase

This will fetch and merge the changes from your original repo master branch (If you have point to that)

这将从您的原始 repo master 分支中获取并合并更改（如果您已指出）

Then you push your changes forcefully to your github cloned repository (target)

然后将更改强行推送到 github 克隆存储库（目标）

git push -f origin master

This will make sure your github clone and the your parent repo are at the same github commit level and you don't see any unnecessary changes across branches.

这将确保您的 github 克隆和您的父存储库处于相同的 github 提交级别，并且您不会跨分支看到任何不必要的更改。

回答by Ishan Srivastava

Fail safe approach if you are too worried about messing things up: go to the file and manually remove the changes, then squash with your last commit using

如果您太担心搞砸事情，则采​​用故障安全方法：转到文件并手动删除更改，然后使用上次提交压缩

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

I there are no conflicts, you are good to go!

我没有冲突，你很好去！