Why does a pull request show extra commits after a rebase?

Question

So I started with a pull request that was a few commits ahead of develop, let's call this branch feature.

feature had 1 merge conflict with develop. So I decided to rebase it and resolve the conflict.

1. git checkout develop git pull
2. git checkout feature git pull
3. git rebase develop
4. Merge conflict fixed - New commit added
5. git rebase --continue
6. Rebase successfull.
7. git push (i was actually using "Synchronize Changes")

After these steps, the PR on GitHub went from having 7 commits, to having 60+ commits.

I would have expected it to only go from 7 to 8 commits, since I fixed one conflict.

Any idea about what happened and how (if needed) to fix it?

I can post additional info if required.

Answer 1

Here is idea what could happen.

This situation may happen when you continue adding commits into branch which will be rebased. Imagine we have two branches master and dev.

master A-B-C
         |
dev      D-E-F

Now we push dev for review.
By the time of waiting for review there is new task. Branch dev gets new commit so locally looks like:

dev A-B-D-E-F-G

Be careful here is no C commit in branch dev. After that your pull request was accepted and you remotely(e.g. in github) rebased your previous changes into master:

master A-B-C-D'-E'-F'

By that time you have branch master with copied D'-E'-F' commits which starts form C commit. But your local dev is different, is has no D'-E'-F' because it has D-E-F. What is more it has not C commit.

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G

And now again you want to add commit G into master with rebase.
The common part for both branches is A-B. So when you reabse, git do not recognise that D' and D are the same because they start from different point (for dev it start form B, for master it start form C). So in preview of new pull request you will see not only commit G but also D-E-F.

Solution

Quick win is to create new branch from actual master, e.g. temp branch.
Cherry-pick new commits into temp. To get hash number of commit just try git log --oneline while on dev.

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G
temp   A-B-C-D'-E'-F'-G

temp branch has all commits that are present on master plus new G commit from dev branch.

[master] git checkout -b temp
[temp]   git cherry-pick 6e687f90 
[temp]   git checkout master
[master] git merge temp

Other possible way is to rebase dev on master and solve all conflicts. Then make pull reqest from dev to master. If there are many duplicated commits on dev this could be the painful process.

Answer 2

Take a look at your branch's git log and try to find anything out of the ordinary.

One comment mentioned using git log, but you can also use git log --graph --oneline to get a visual representation of your branch's commit history. If your branch was rebased correctly, you would see something along the lines of:

* 5eccc30d1 (HEAD -> feature, origin/feature) # Your commit message 8
* 5f73d262a # Your commit message 7
* 6c636b744 # Your commit message 6
* 97e17a7cf # ...
* 596297507 # ...
* 4646ce633 # ...
* 9fb61eb95 # ...
* 38dab17ae # Your commit message 1
*   7532142f7 (origin/develop) Merge pull request #...
|\
| * 042303c7e Add feature
* |   008f1e53b Merge pull request #...
|\ \
| * | 5a398f715 Fix issue with #...
# And so on

Compare with this and try to find anything out of the ordinary. The commit below your first commit should be your base branch, and there should be no commits mixed in among the ones your wrote.

I suspect there might be an issue with using git pull with your feature branch. If you are working on this PR yourself there shouldn't be reason to do this, and something could be going wrong because of it.

If you need to pull with your feature branch, try using git pull --rebase instead, which is equivalent to a fetch and a rebase, instead of a fetch and a merge. This ensures your local commits stay on top of your history, in case there are differences between your local branch and your origin.