How did these git commits get duplicated into the wrong branch?

Question

I'm trying to help a coworker figure out what a bunch of "empty commit" warnings were about in his recent merge. I opened up gitk, and saw something like this:

 _o (Z) Merge branch 'new-branch'                             (yesterday)
o | (Y) Fix bad merge                                         (person 1)
o_| (X) Merge branch 'master' into new-branch                 (recent)
o | (W) Last legitimate commit that belongs on new-branch     (person 1) 
| |     ... work on master ...
o | (F) Legitimate commit that actually belongs on new-branch (person 2)
| |     ... work on master ...
o | (E) Legitimate commit that should have been on master     (person 2)
o | (D') Even more work etc...                                (committed by person 2)
o | (C') More work in master                                  (committed by person 2)
o | (A') Normal work in master                                (committed by person 2)
| o (D) Even more work etc...                                 (authored by random person)
| o (C) More work in master                                   (authored by random person)
o | (B) Starting to work on new-branch                        (person 1)
|_o (A) Normal work in master                                 (authored by random person)
o Common Ancestor                                             (weeks ago)

So obviously the two people working on this branch should have merged from master into their branch more often, and then these piles of merge warnings would have been more obvious. The team member whose name was in the committer field of the duplicated commits says he probably did a pull --rebase to cause them, but I can't wrap my head around how that could work. Can anyone explain what might have happened?

I'm not looking for a way to fix the merge warnings, since they seemed benign. I just want to understand what happened so I can prevent it from happening in the future. My team is relatively new to git, so I'm trying to help them understand it one small step at a time, using trial and error for the most part.

Thanks!

Answer 1

When you do a rebase on a branch, you rewrite that branch's history. All the affected commits will have their IDs changed at least (even if there was no content change within the commit). Because of this, it might appear as if you are having duplicate commit(s), which you actually don't. You have two different commits with the same content.

The way to reproduce this "duplicate commits" behavior is usually to do a rebase of a branch that has been already pushed to a remote repository and then merge it back to that same remote branch. The rebase will change the IDs of your commits and the merge will keep both pairs of "duplicate" commits, even though their changes will result in the same content.

1. In your existing repository, create a new "feature" branch from the "master" branch: git checkout -b feature
2. Add a new file "file-feature.txt" and commit it on the "feature" branch: git add . ; git commit -m "added new file on master branch"
3. Switch to the "master" branch and add a different new file there and commit that, too: git checkout master ; git add . ; git commit -m "added new file on master branch"
4. Push the feature branch on the remote repository: git checkout feature ; git push --set-upstream origin feature
5. Now, do a rebase of the "feature" branch onto "master" branch: git rebase master
6. If you now try to push this "feature" branch to the remote repository, you'll get an error that you need to do a "git pull" first. This is the point where you actually get your "duplicate" commits, because of the merge (git pull is a shorthand for git fetch ; git merge), also remember that commits' content are the same, but due to the rebase of the branch, the commits' IDs are different now and thus, they are being considered as a different thing, so: git pull
7. Inspect your branch now in a GUI, with "git gui" (navigate to the main menu - Repository - Visualize feature's History) and you'll see something like this:
8. Or just use git log to see it directly in the command line: