I'm working on a project (alone) and for every feature I develop I create a new branch, work on this feature, then merge it to master. So normally I never work on two different branches at one time and never touch master while working on a branch.
When I merge a branch I see that (using gitx and gitk) the history of master branch gets all the commits I've done to the merged branch. I mean if I have something like:
master a-b-c-d
\z-x-y--
|branch name
after merge I get:
a-b-c-d-z-x-y
|branch name
Yes, I see the merged branch name highlighted (using gitx and gitk), but what I was expecting is something showing exactly where commits are done (to which branch) like:
master a-b-c-d--------M--
\-z-x-y-/
|branch name
So I'm expecting to see a commit "M" that represents the merge I've done to master, not to look like that all commits I've done to the new branch have been done to master.
Is my expectation correct? Or this is normal git behaviour?
That is normal Git behaviour. You are doing what is called a "fast-forward" merge, because your branch is strictly ahead of the master branch.
If you really want to preserve branch history (although I'd recommend you don't bother) then you can use git merge --no-ff to force it to create a merge commit even when it can do a fast-forward update.
You can found addition criticism to the -no-ff option in "Understanding the Git Workflow", mainly because it would break git blame.
More at "fast forward when using pull and no-ff when pull".
As explained in "Why does git use fast-forward merging by default?", unless you are talking about a really long-lived branch, a fast-forward merge is preferable.
来源：https://stackoverflow.com/questions/7274938/git-branches-commits-history-after-merge