I'm w开发者_运维知识库orking 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.
精彩评论