I forked a project on Github, made a small change and sent a pull request to the original maintainer, who has pulled it in. Now the last commit there is Merged pull request #11 from my_username/master.

This is the first time I'm doing this, so I'm not sure what the etiquette now is: I did a git pull upstream master and then git push origin master, and now the last commit on my own repository reads Merged pull request #11 from my_username/master which feels pretty weird to me. Is this the way people usually do it, is there anything I need to do to "clean up the history" or something?

Note: since this was a tiny documentation change, I hadn't created any branches, I just made the change in my master branch and sent the pull req. So there's no cleanup to be done in that part.

1 Answer 1


Yes, this is what people usually do, because it is what git does.

The merge tests often don't make sense. It is the result of the "fast forward" logic, i.e. merging does not create new commit if it is not necessary. Most of the time last commit on master says "merged master", because the developer merged master to their branch and pushed to merge, which didn't need any more merges. Nobody cares about merge commits in git anyway.

  • 5
    If you do care, however, you may find the no-ff option of git merge useful when merging to master.
    – Xion
    Commented Aug 26, 2013 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.