GitHub pull request showing commits that are already in target branch
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?
I’ve also checked out the pull request locally and it only shows the un-merged commits.
- Can a pullrequest on bitbucket be locked for further commits?
- Squash feature branch commit after merging from master
- git rebase after pull request
- How to checkout a forked pull request locally in SourceTree?
- Add commits to a pull request as a repo's owner
- Set the develop branch as the default for a pull request
6 Solutions collect form web for “GitHub pull request showing commits that are already in target branch”
It looks like the Pull Request doesn’t keep track of changes to the target branch (I contact 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:
currentbranch as needed.
It’s a shame this doesn’t happen automatically.
One way to fix this is to
git rebase targetbranch in 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 targetbranch to make sure it is still what you want.
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.
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)
Then you push your changes forcefully to your github cloned repository (target)
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.
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
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
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
You need to add the following to your
[rebase] autosquash = true
This will automatically achieve the same as what this answer shows.
I got this from here.