GitHub pull request showing commits that are already in target branch

Question

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 merg

Answer 1

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

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.

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

Answer 2

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

Answer 3

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).

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 currentbranch as needed.

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

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 entries in the PR:

Answer 4

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.

More information available here: 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.

Answer 5

Try the below commands, one by one.

git pull "latest

git reset --hard master

Answer 6

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

Solution 1: Rebase

Suppose that you want to merge into master from 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 origin above with upstream. See How do I update a GitHub forked repository? to learn more about tracking remote branches of the original repository.

Solution 2: Create a new pull request

Suppose that you want to merge intro master from 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-rebased and close the one for feature-01.