GitHub pull request showing commits that are already in target branch
GitGithubMergeCommitPull RequestGit Problem Overview
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.
Git Solutions
Solution 1 - Git
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.
Solution 2 - Git
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:
Solution 3 - Git
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-with-lease
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
.
Solution 4 - Git
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
Solution 5 - Git
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.
Solution 6 - Git
You need to add the following to your ~/.gitconfig
file:
[rebase]
autosquash = true
This will automatically achieve the same as what this answer shows.
I got this from here.
Solution 7 - Git
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.
Solution 8 - Git
Instead of the 3-dot url use 2-dot url to compare
Instead of
http://githuburl/org/repo/compare/targetbranch...currentbranch
Use
http://githuburl/org/repo/compare/targetbranch..currentbranch
Solution 9 - Git
What I tried and why it's happening?
None of the solutions worked for me. When I used two dots i.e. ..
instead of ...
the diff on GH was much closer to what I changed. But still not exactly all my changes.
This happens because a problem in how GitHub shows squash merged changes. Best explained here
It basically happens if:
- Push up changes of
featureBranch
- Squash merge it into
main
- Locally while I'm still on
featureBranch
I merge it withmain
. Make more changes and push it up again. - But then on GitHub I see more changes than I expect.
It's worth noting that this isn't a git problem. Instead it's a GitHub problem. GitHub
can't tell that the squashed commit is identical the sum of the non-squash commits and causes an extra diff.
Solution
On your local main, undo and stash all changes that haven't been merged with main. To do that I did. Example if I had 4 commits that weren't in my PR that got squash merged then I'd do:
git reset HEAD~4
git stash save "last 4 commits"
Then create a new branch with what you've just stashed. Steps:
git checkout main
git checkout -b newBranch
git stash apply
git add --all
git commit -m "some message"
git push
Solution 10 - Git
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.
Solution 11 - Git
I found a way to get the right behavior (tested in November 2020).
After git merge
and resolving conflicts need to use git merge --continue
instead of git commit ...
.
Solution 12 - Git
The issue is not happening for me once i started doing the following before starting a new change or creating a PR.
git pull --rebase origin <target-branch>
This basically ensures that whatever new changes are added from the local is stacked on top of what is there currently in the remote branch. Hence our local branch is always on top of the current remote head and only the new commits are there in the PR.
Solution 13 - Git
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!