Github still shows differences between branches after sucessfull merge

Question

Recently I merged a huge pull request (140 commits) from the feature branch to master:

I can see the merge in the github overiew on the master branch:

Answer 1

as @matt is saying, you probably didn't merge but squashed or rebased or something. The best you can do then is rebase that single revision on top of the base branch:

git checkout feature-branch
git rebase --onto origin/the-base-branch feature-branch~ feature-branch

That will put the branch on top of the base branch... you will probably have to force-push if you are using the same branch that you used before to create the PR because that history was not really merged into the base branch so a normal push will fail.

Answer 2

It looks like you're using two long-running branches and using a squash merge. That's a bit of a problem, and here's why.

When Git performs a merge, it considers exactly three points: the two heads you're merging, and a third point, called the merge base, which is usually their common ancestor. The result of the merge is the sum of the changes between the merge base and each head.

If you merge two branches with a normal merge commit, then you create a new common ancestor, so future merges start at that base. You don't have to worry about conflicts from things you've already merged because Git doesn't even consider them.

When you merge two branches with a squash merge, you create a single commit on one branch that includes all of the changes from the other, but you don't create a new common ancestor. As a result, Git looks at all the changes on both sides when you try to merge again and you can end up with a lot of conflicts. This only gets worse if you keep squash merging the two branches.

As a result, you really must use a normal merge commit to integrate two long-running branches unless you really want to resolve lots of conflicts all the time. Squash merges won't work here.

If feature doesn't need to be long-running, then simply recreate it from master. Git is great at creating feature branches that you can then throw away once they're merged. That's the simplest way to solve this problem. Since you have a commit on it that needs to be included, then just follow the steps similar to those eftshift0 outlined:

$ git checkout feature
$ git rebase --onto master HEAD^
# optionally:
$ git push origin +feature

Otherwise, here's the easiest way to solve this problem. Take the commit on master immediately before your squash merge and call it A. Take the commit on feature that you merged and call it B.

$ git checkout -b temp A
$ git merge B
$ git checkout master
$ git merge temp

This creates a branch called temp which looks exactly like the squash merge, but with a real merge commit, and then merges it into master. This merges is a no-op because both sides are completely identical, so you don't have to resolve any conflicts. However, both sides now share a new common ancestor on which future merges can be based, which solves the problem. You can then use normal merge commits when integrating the two branches.